From cyrille.lefevre at laposte.net  Fri May 10 14:43:51 2002
From: cyrille.lefevre at laposte.net (Cyrille Lefevre)
Date: Fri, 10 May 2002 06:43:51 +0200 (CEST)
Subject: [pups] lcc (was: GCC)
In-Reply-To: <20020121105423.B4262@wantadilla.lemis.com>
Message-ID: <200205100443.g4A4hpRB040128@gits.gits.dyndns.org>

Greg Lehey wrote:
> It's in the FreeBSD Ports Collection as /usr/ports/lang/lcc, but it's
> still version 3.6; if you update it for more recent versions, let me
> know and I'll commit it.

your port tree isn't up-to-date anymore :)

$ cvs log ports/lang/lcc/Makefile
...
revision 1.15
date: 2002/04/12 19:29:14;  author: ade;  state: dead;  lines: +1 -1
Remove lang/lcc -- it's been broken for so long and there is no new
version.

Cyrille.
-- 
Cyrille Lefevre                 mailto:cyrille.lefevre at laposte.net


From grog at lemis.com  Fri May 10 15:08:31 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 10 May 2002 14:38:31 +0930
Subject: [pups] lcc (was: GCC)
In-Reply-To: <200205100443.g4A4hpRB040128@gits.gits.dyndns.org>
References: <20020121105423.B4262@wantadilla.lemis.com> <200205100443.g4A4hpRB040128@gits.gits.dyndns.org>
Message-ID: <20020510143831.A413@wantadilla.lemis.com>

On Friday, 10 May 2002 at  6:43:51 +0200, Cyrille Lefevre wrote:
> Greg Lehey wrote:
>> It's in the FreeBSD Ports Collection as /usr/ports/lang/lcc, but it's
>> still version 3.6; if you update it for more recent versions, let me
>> know and I'll commit it.
>
> your port tree isn't up-to-date anymore :)

Not at all.

> $ cvs log ports/lang/lcc/Makefile
> ...
> revision 1.15
> date: 2002/04/12 19:29:14;  author: ade;  state: dead;  lines: +1 -1
> Remove lang/lcc -- it's been broken for so long and there is no new
> version.

Your MUA doesn't note the date of the message to which you were
replying.  It was 22 January, long before this commit.

Greg 
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From schoedel at kw.igs.net  Fri May  3 13:51:40 2002
From: schoedel at kw.igs.net (Kevin Schoedel)
Date: Thu, 2 May 2002 23:51:40 -0400
Subject: [TUHS] Some tapes
Message-ID: <v04210101b8f7b991be5c@[216.58.99.179]>

I've just obtained a box of tapes, some of which might be of interest here.

- UNIX/32V V1.0 (w/ typed Bell Labs label): one 2400' 800bpi tape
- Ultrix-32M V1.1 distribution: one 2400' dump tape
- Ultrix-32 & 32M V1.1 Sources: two 2400' 1600bpi tar tapes (2 copies each)
- BSD4.1 distribution: one 2400' 1600bpi tape
- UNIX V5 (handwritten label dated Feb 7 1977): one 2400' tape
- one 400' tape with missing identification label but a typed Bell
  Labs notice
- backup of 2 RKs: V6 UNIX master and V6 UNIX additional source:
  one 400' 800bpi tape
- C Release 29/9/80 (handwritten): one 2400' tape
- several backup tapes from a V7 system
- several other tapes that appear to be other UNIX system backups

I don't have a 9-track drive, so I can't say that these will be readable (or
even that they haven't been bulk-erased), but I do believe that they have at
least been stored well so far. If any of these look like they could contain
things currently missing from the archives, then I do of course want to make
them available to someone who can try to read them.

-- 
Kevin Schoedel
schoedel at kw.igs.net


From grog at lemis.com  Fri May  3 14:18:17 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 3 May 2002 13:48:17 +0930
Subject: [TUHS] Some tapes
In-Reply-To: <v04210101b8f7b991be5c@[216.58.99.179]>
References: <v04210101b8f7b991be5c@[216.58.99.179]>
Message-ID: <20020503134817.Q12386@wantadilla.lemis.com>

On Thursday,  2 May 2002 at 23:51:40 -0400, Kevin Schoedel wrote:
> I've just obtained a box of tapes, some of which might be of interest here.
>
> - UNIX/32V V1.0 (w/ typed Bell Labs label): one 2400' 800bpi tape
> - Ultrix-32M V1.1 distribution: one 2400' dump tape
> - Ultrix-32 & 32M V1.1 Sources: two 2400' 1600bpi tar tapes (2 copies each)
> - BSD4.1 distribution: one 2400' 1600bpi tape
> - UNIX V5 (handwritten label dated Feb 7 1977): one 2400' tape

Yes!  Do you know if it's source or object?

> - one 400' tape with missing identification label but a typed Bell
>   Labs notice
> - backup of 2 RKs: V6 UNIX master and V6 UNIX additional source:
>   one 400' 800bpi tape
> - C Release 29/9/80 (handwritten): one 2400' tape
> - several backup tapes from a V7 system
> - several other tapes that appear to be other UNIX system backups
>
> I don't have a 9-track drive, so I can't say that these will be readable (or
> even that they haven't been bulk-erased), but I do believe that they have at
> least been stored well so far. If any of these look like they could contain
> things currently missing from the archives, then I do of course want to make
> them available to someone who can try to read them.

This is excellent news.  So far, nobody has been able to find sources
for the fourth or fifth editions, so that one tape would be excellent
if it's readable.  I'm sure that people close to you (US east coast)
will make themselves known.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From schoedel at kw.igs.net  Fri May  3 15:07:05 2002
From: schoedel at kw.igs.net (Kevin Schoedel)
Date: Fri, 3 May 2002 01:07:05 -0400
Subject: [TUHS] Some tapes
In-Reply-To: <20020503134817.Q12386@wantadilla.lemis.com>
References: <v04210101b8f7b991be5c@[216.58.99.179]>
 <20020503134817.Q12386@wantadilla.lemis.com>
Message-ID: <v04210102b8f7c271d43e@[216.58.99.179]>

>> - UNIX V5 (handwritten label dated Feb 7 1977): one 2400' tape
>
>Yes!  Do you know if it's source or object?

No idea. I assume it's a system backup tape, rather than a distribution tape,
since it has six dates written on the label, the last marked 'archived. One
can hope that the system had sources online; it is a 2400' tape, and a slight
difference in appearance between the inside and outside suggests it might be
about 2/3 full. (These tapes, by the way, came from the University of
Waterloo.)

There's also that unidentified short tape with a Bell Labs notice -- is the
wording enough to identify the version (assuming it is a UNIX tape)? This one
reads "THIS INFORMATION IS PROPRIETARY AND IS THE PROPERTY OF BELL TELEPHONE
LABORATORIES, INC. ITS REPRODUCTION OR DISCLOSURE TO OTHERS, EITHER ORALLY OR
IN WRITING, IS PROHIBITED WITHOUT WRITTEN PERMISSION OF BELL LABORATORIES."

-- 
Kevin Schoedel
schoedel at kw.igs.net


From grog at lemis.com  Fri May  3 16:04:54 2002
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Fri, 3 May 2002 15:34:54 +0930
Subject: [TUHS] Some tapes
In-Reply-To: <v04210102b8f7c271d43e@[216.58.99.179]>
References: <v04210101b8f7b991be5c@[216.58.99.179]> <20020503134817.Q12386@wantadilla.lemis.com> <v04210102b8f7c271d43e@[216.58.99.179]>
Message-ID: <20020503153454.V12386@wantadilla.lemis.com>

On Friday,  3 May 2002 at  1:07:05 -0400, Kevin Schoedel wrote:
>>> - UNIX V5 (handwritten label dated Feb 7 1977): one 2400' tape
>>
>> Yes!  Do you know if it's source or object?
>
> No idea. I assume it's a system backup tape, rather than a distribution tape,
> since it has six dates written on the label, the last marked 'archived. One
> can hope that the system had sources online; it is a 2400' tape, and a slight
> difference in appearance between the inside and outside suggests it might be
> about 2/3 full. (These tapes, by the way, came from the University of
> Waterloo.)

Ah, well, let's hope.

> There's also that unidentified short tape with a Bell Labs notice -- is the
> wording enough to identify the version (assuming it is a UNIX tape)? This one
> reads "THIS INFORMATION IS PROPRIETARY AND IS THE PROPERTY OF BELL TELEPHONE
> LABORATORIES, INC. ITS REPRODUCTION OR DISCLOSURE TO OTHERS, EITHER ORALLY OR
> IN WRITING, IS PROHIBITED WITHOUT WRITTEN PERMISSION OF BELL LABORATORIES."

I think that's pretty generic.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers


From wkt at minnie.tuhs.org  Fri May  3 17:51:52 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Fri, 3 May 2002 17:51:52 +1000 (EST)
Subject: [TUHS] Some tapes
In-Reply-To: <20020503134817.Q12386@wantadilla.lemis.com> from "Greg 'groggy'
 Lehey" at "May 3, 2002 01:48:17 pm"
Message-ID: <200205030751.g437pqH28832@minnie.tuhs.org>

In article by Greg 'groggy' Lehey:
> > I've just obtained a box of tapes, some of which might be of interest here.

I've passed Kevin's e-mail on to Tim Shoppa, but are there any other
volunteers who could read these tapes for us?

> This is excellent news.  So far, nobody has been able to find sources
> for the fourth or fifth editions, so that one tape would be excellent
> if it's readable.  I'm sure that people close to you (US east coast)
> will make themselves known.

Close, we have 5th Edition source but no man pages :)

	Warren


From mike at ducky.net  Fri May  3 18:13:55 2002
From: mike at ducky.net (Mike Haertel)
Date: Fri, 3 May 2002 01:13:55 -0700 (PDT)
Subject: [TUHS] Some tapes
Message-ID: <200205030813.g438DtM2022178@ducky.net>

I'd also like to point out that the 4.1BSD distribution tape would
be a nice addition to the TUHS archive.  Right now 4.0, 4.1, and
4.1[abc] distributions are still missing.


From arnold at skeeve.com  Fri May  3 20:29:30 2002
From: arnold at skeeve.com (Aharon Robbins)
Date: Fri, 03 May 2002 12:29:30 +0200
Subject: [TUHS] Some tapes
Message-ID: <200205030930.g439Uoo15310@lmail.actcom.co.il>

> From: Mike Haertel <mike at ducky.net>
> To: tuhs at tuhs.org
> Subject: Re: [TUHS] Some tapes
> Date: Fri, 3 May 2002 01:13:55 -0700 (PDT)
>
> I'd also like to point out that the 4.1BSD distribution tape would
> be a nice addition to the TUHS archive.  Right now 4.0, 4.1, and
> 4.1[abc] distributions are still missing.

These are available from Kirk McKusick on his 4-CD collection, no?
It'd be good to have them in w/the other stuff all in one place, but
it's not like they aren't available...

Arnold



From wkt at minnie.tuhs.org  Fri May  3 20:02:47 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Fri, 3 May 2002 20:02:47 +1000 (EST)
Subject: [TUHS] Some tapes
In-Reply-To: <200205030930.g439Uoo15310@lmail.actcom.co.il> from Aharon Robbins
 at "May 3, 2002 12:29:30 pm"
Message-ID: <200205031002.g43A2mE30088@minnie.tuhs.org>

In article by Aharon Robbins:
> > I'd also like to point out that the 4.1BSD distribution tape would
> > be a nice addition to the TUHS archive.  Right now 4.0, 4.1, and
> > 4.1[abc] distributions are still missing.
> 
> These are available from Kirk McKusick on his 4-CD collection, no?
> It'd be good to have them in w/the other stuff all in one place, but
> it's not like they aren't available...
> Arnold

For most of the 4BSD releases, Kirk's CSRG 4-CD set unfortunately only
has source files: no binaries, no boot records, no bootable tape images.
This does make it hard to resurrect these systems on original hardware
or simulators.

Cheers,
	Warren


From jkunz at unixag-kl.fh-kl.de  Fri May  3 21:13:31 2002
From: jkunz at unixag-kl.fh-kl.de (Jochen Kunz)
Date: Fri, 3 May 2002 13:13:31 +0200
Subject: [TUHS] Some tapes
In-Reply-To: <200205031002.g43A2mE30088@minnie.tuhs.org>; from wkt@minnie.tuhs.org on Fri, May 03, 2002 at 08:02:47PM +1000
References: <200205030930.g439Uoo15310@lmail.actcom.co.il> <200205031002.g43A2mE30088@minnie.tuhs.org>
Message-ID: <20020503131331.A21649@unixag-kl.fh-kl.de>

On Fri, May 03, 2002 at 08:02:47PM +1000, Warren Toomey wrote:

> For most of the 4BSD releases, Kirk's CSRG 4-CD set unfortunately only
> has source files: no binaries, no boot records, no bootable tape images.
> This does make it hard to resurrect these systems on original hardware
> or simulators.
Yes. And if there are binaries, like for 4.4BSD-Lite, they are on 
the ISO file system, not in tar archives. So many file system attributes
like links are lost, device nodes are plain files, ... 
I made 4.4BSD-Lite working on my HP9000 433t, but it was a bit
complicated, required a netbooted NetBSD, problems with disklabel
differences 4.4BSD <=> NetBSD, ... It works now (more or less) 
and when I have the time I work on a build to update the machine
to the final 4.4BSD-Lite2. 
e.g. 4.3BSD-Reno binaries for HP9000 300 would be fine. VAX binaries 
are already in the archive. With that you can put a VAX and a HP300 
side by side and see and feel the the difference from architecture
to architecture. The same for 4.4BSD on HP300, SPARC, PMAX, ...
Or some 4.[012]BSD on a VAX 11/7[35]0. Are you willing to rebuild
the world on a 0.3 / 0.6 VUP machine with <= 2MB RAM? 
-- 



tschüß,
         Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/



From mike at ducky.net  Sat May  4 02:53:45 2002
From: mike at ducky.net (Mike Haertel)
Date: Fri, 3 May 2002 09:53:45 -0700 (PDT)
Subject: [TUHS] Some tapes
In-Reply-To: <200205030930.g439Uoo15310@lmail.actcom.co.il>
Message-ID: <200205031653.g43GrjaH023372@ducky.net>

>> I'd also like to point out that the 4.1BSD distribution tape would
>> be a nice addition to the TUHS archive.  Right now 4.0, 4.1, and
>> 4.1[abc] distributions are still missing.
>
>These are available from Kirk McKusick on his 4-CD collection, no?
>It'd be good to have them in w/the other stuff all in one place, but
>it's not like they aren't available...

I have Kirk's 4-CD collection.  Here's what it has for each version
I mentioned:

4.0	binaries + sources (fully unpacked tree of installed system)
	no tape images, however there are already-built standalone
	program binaries in /usr/src/sys/stand, so it might be feasible
	to roll your own.  the hardest part would be creating a
	root dump.

4.1	binaries + sources (fully unpacked tree of installed system)
	no tape images, but similar prebuilt stuff in /usr/src/sys/stand.

4.1a	just some contents from a "Tape #2" - VERY incomplete.
	some games binaries, some games and command sources, and
	some documents.  *no* kernel sources, regular binaries.

4.1b	missing entirely

4.1c.1	just a tree of /usr/src, with a /usr/src/sys tree of unknown origin

4.1c.2	partial tape image: has mkfs program, and what looks like a
	root dump (but not 100% sure).  the rest is untarred, but
	I'm guessing the remaining tape files were just in tar
	format anyway.  prebuilt binaries for standalone programs.
	somewhat bizarrely, the kernel sources are in /a/sys and
	/sys (on the CDROM) is a broken symbolic link.  this is
	obviously a snapshot of a working system rather than a more
	formal distribution.

Anyway, as Warren already explained, the lack of distribution tape images
makes it hard to install these in an emulator if you want to play with them!


From sven_dehmlow at web.de  Mon May  6 01:52:44 2002
From: sven_dehmlow at web.de (Sven Dehmlow)
Date: Sun, 5 May 2002 17:52:44 +0200
Subject: [TUHS] ancient unix filesystems
Message-ID: <02050517524400.00615@linux>

Hi,
I'm currently working on an implementation of the Unix 6th Edition's 
filesystem for Linux. I think earlier Unix filesystems should be very 
similar to it. I would like to implement them, too, but I don't have 
exact descriptions of them (for the 6th Edition I've the Lions Book; 
there is not much about the actual filesystem architecture in it, but 
it should be enough - together with the code ;-).

Please send me descriptions, specifications and everything else 
you've about the early Unix filesystems. Also filesystem images are 
very welcome as I can use them to test my implementation.
My e-mail account can only handle attachments <3000KB. Please 
compress or split the files if they are bigger than 3000KB.

Thank you
Sven


From helbig at Informatik.BA-Stuttgart.DE  Mon May  6 10:07:40 2002
From: helbig at Informatik.BA-Stuttgart.DE (Wolfgang Helbig)
Date: Mon, 6 May 2002 02:07:40 +0200 (MEST)
Subject: [TUHS] ancient unix filesystems
Message-ID: <200205060019.g460JRK01697@bsd.korb>

>exact descriptions of them (for the 6th Edition I've the Lions Book; 
>there is not much about the actual filesystem architecture in it, but 
>it should be enough - together with the code ;-).

You might want to run V6 or V5 on a simulator. For one you can "see"
the filesystem and you can read the man pages, especially fs(5).

Wolfgang



From wkt at minnie.tuhs.org  Mon May  6 11:00:45 2002
From: wkt at minnie.tuhs.org (Warren Toomey)
Date: Mon, 6 May 2002 11:00:45 +1000 (EST)
Subject: [TUHS] ancient unix filesystems
In-Reply-To: <02050517524400.00615@linux> from Sven Dehmlow at "May 5, 2002 05:52:44
 pm"
Message-ID: <200205060100.g4610ki71011@minnie.tuhs.org>

In article by Sven Dehmlow:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi,
> I'm currently working on an implementation of the Unix 6th Edition's 
> filesystem for Linux. I think earlier Unix filesystems should be very 
> similar to it. I would like to implement them, too, but I don't have 
> exact descriptions of them (for the 6th Edition I've the Lions Book; 
> there is not much about the actual filesystem architecture in it, but 
> it should be enough - together with the code ;-).
> 
> Please send me descriptions, specifications and everything else 
> you've about the early Unix filesystems. Also filesystem images are 
> very welcome as I can use them to test my implementation.
> My e-mail account can only handle attachments <3000KB. Please 
> compress or split the files if they are bigger than 3000KB.
> 
> Thank you
> Sven

Sven, you might want to look at this:
http://minnie.tuhs.org/cgi-bin/pups.cgi?article=2170

  From: Stuart Norris <norris at euler.mech.eng.usyd.edu.au>

 I have hacked together a version of a Unix 5th (and 6th) 
 Edition filesystem for Linux. It is read only, and was written for 
 Linux 2.0 on an x86 and so will require a little work to install on
 other systems and newer kernels, but it is fun to be able to mount 
 old disk images.

Cheers,
	Warren


From s.norris at auckland.ac.nz  Mon May  6 13:59:43 2002
From: s.norris at auckland.ac.nz (Stuart Norris)
Date: Mon, 6 May 2002 15:59:43 +1200
Subject: [TUHS] Re: ancient unix filesystems
In-Reply-To: <200205060206.g4626vm71633@minnie.tuhs.org>
Message-ID: <Pine.SGI.4.20.0205061551310.132659-100000@esu51>

On Mon, 6 May 2002 tuhs-request at minnie.tuhs.org wrote:

> From: Warren Toomey <wkt at minnie.tuhs.org>
> 
> Sven, you might want to look at this:
> http://minnie.tuhs.org/cgi-bin/pups.cgi?article=2170
> 
>   From: Stuart Norris <norris at euler.mech.eng.usyd.edu.au>
> 
>  I have hacked together a version of a Unix 5th (and 6th) 
>  Edition filesystem for Linux. It is read only, and was written for 
>  Linux 2.0 on an x86 and so will require a little work to install on
>  other systems and newer kernels, but it is fun to be able to mount 
>  old disk images.

The source code is sitting on

	http://www.esc.auckland.ac.nz/People/Staff/Norris/src/u5e-0.2.tar.gz

and the INTRO file contains a description of the filesystem. I don't think
it works with current Linux kernels (I havn't touched it for a long while),
so it might be easiest to start afresh using the minix filesystem module
as a start.

Briefly, the filesystem is like

--

* Block size:	512

* General layout:
  Block 0			boot block
  Block 1			super block
  Blocks 2 -> isize-1		inodes
  Blocks isize -> fsize-1	data blocks

* Byte ordering of "short" (16 bit entities) is little endian 0 1

* Byte ordering of "long" (32 bit entities) is PDP-11 2 3 0 1

* Inode on disk: "short"
	0	means non-existent
	1	root dir

* Maximum number of hard links to a file:	256

* Super-block location: bytes 512-1023

* Super-block layout:
	unsigned short  s_isize;     /* size in blocks of I list */
	unsigned short  s_fsize;     /* size in blocks of entire volume */
	unsigned short  s_nfree;     /* number of in core free blocks (0-100) */
	unsigned short  s_free[100]; /* in core free blocks */
	unsigned short  s_ninode;    /* number of in core I nodes (0-100) */
	unsigned short  s_inode[100];/* in core free I nodes */
	char            s_flock;     /* lock during free list manipulation */
	char            s_ilock;     /* lock during I list manipulation */
	char            s_fmod;      /* super block modified flag */
	char            s_ronly;     /* mounted read-only flag */
	unsigned long   s_time;      /* current date of last update */

* Inode layout:
	unsigned short i_mode;    /* access permissions */
	unsigned char  i_nlink;   /* number of links to file */
	unsigned char  i_uid;     /* owner */
	unsigned char  i_gid;     /* group */
	unsigned char  i_size0;   /* size of file */
	unsigned short i_size1;
	unsigned short i_addr[8];/* address of blocks */
	unsigned long  i_atime;  /* time of last access */
	unsigned long  i_mtime;  /* time of last modification */

* Regular file data blocks are organized as
	if (010000 bit set)
		the file is large:
		i_addr[] contains indirect blocks
	else
		the file is small:

* Inode size 32, 16 inodes per block

* Directory entry on disk
	unsigned short inode;
	char name[14];

* Dir entry size 16, 32 dir entries per block

* There are no symbolic links


--
Stuart Norris                                          s.norris at auckland.ac.nz
Bioengineering Institute, University of Auckland    hm: +(64 9) 307 0006
http://www.esc.auckland.ac.nz/People/Staff/Norris   wk: +(64 9) 373 7599 x3055



From bqt at update.uu.se  Tue May  7 02:38:55 2002
From: bqt at update.uu.se (Johnny Billquist)
Date: Mon, 6 May 2002 18:38:55 +0200 (CEST)
Subject: [TUHS] Some tapes
In-Reply-To: <v04210101b8f7b991be5c@[216.58.99.179]>
Message-ID: <Pine.LNX.4.21.0205061838210.18261-100000@Tempo.Update.UU.SE>

On Thu, 2 May 2002, Kevin Schoedel wrote:

> I've just obtained a box of tapes, some of which might be of interest here.

I could handle 800, 1600 and 6250 bpi. But I'm in Sweden.

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt at update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



From sven_dehmlow at web.de  Wed May  8 03:15:50 2002
From: sven_dehmlow at web.de (Sven Dehmlow)
Date: Tue, 7 May 2002 19:15:50 +0200
Subject: [TUHS] Re: ancient unix filesystems
In-Reply-To: <Pine.SGI.4.20.0205061551310.132659-100000@esu51>
References: <Pine.SGI.4.20.0205061551310.132659-100000@esu51>
Message-ID: <02050719155000.00761@linux>

On Monday 06 May 2002 05:59, Stuart Norris wrote:
> On Mon, 6 May 2002 tuhs-request at minnie.tuhs.org wrote:
> > From: Warren Toomey <wkt at minnie.tuhs.org>

Thank you very much!

Sven


From chd_1 at nktelco.net  Wed May  8 08:59:09 2002
From: chd_1 at nktelco.net (Chuck Dickman)
Date: Tue, 07 May 2002 18:59:09 -0400
Subject: [TUHS] ancient unix filesystems --- on current Unix implementations
Message-ID: <3CD85C3D.22602C76@nktelco.net>

Does anyone know how many of the V5, V6, V7, 2BSD, 2.11BSD, etc. filesystems are
implemented in some current unix implementations, NetBSD, Linux, etc. Seems like
that could be useful when playing with simh.

-chuck


From sven_dehmlow at web.de  Thu May  9 04:39:42 2002
From: sven_dehmlow at web.de (Sven Dehmlow)
Date: Wed, 8 May 2002 20:39:42 +0200
Subject: [TUHS] ancient unix filesystems --- on current Unix implementations
In-Reply-To: <3CD85C3D.22602C76@nktelco.net>
References: <3CD85C3D.22602C76@nktelco.net>
Message-ID: <02050820394200.00624@linux>

On Wednesday 08 May 2002 00:59, Chuck Dickman wrote:
> Does anyone know how many of the V5, V6, V7, 2BSD, 2.11BSD, etc.
> filesystems are implemented in some current unix implementations,
> NetBSD, Linux, etc. Seems like that could be useful when playing
> with simh.

As far as I'm aware of there are currently no implementations of the 
filesystems mentioned above for Linux 2.5. I think the oldest Unix 
filesystems implemented are Minix FS, Xenix FS, SystemV FS and 
perhaps Coherent FS. Look at the fs/sysv directory in the Linux 
kernel to learn more about them. 

Send me more informations about the 2BSD and 2.11BSD filesystems and 
I will try to implement them for Linux (after I finished 5th,6th and 
7th Edititons' filesystems).

Sven



From rp at servium.ch  Thu May 23 04:03:02 2002
From: rp at servium.ch (Rico Pajarola)
Date: Wed, 22 May 2002 20:03:02 +0200 (CEST)
Subject: [TUHS] simh vax and 4.3-quasijarus
Message-ID: <20020522180302.7508F40E821@enigma.cybertime.ch>

I installed 4.3-quasijarus on simh, and I managed to boot indirectly
by putting the kernel as /quasijarus0a in the netbsd root filesystem,
and then booting it from the netbsd bootloader with 'boot quasijarus0a
-a'. I have been unable to boot it directly from it's 'own'
filesystem.

here's what I see, complete transcript at the end
> >>>boot dua0
> (BOOT/R5:0 DUA0)
> 
> 
> 
>   2..
> -DUA0
> HALT instruction, PC: 00000C1A (MOVL (R11),SP)

that's obviously not what I want. I tried all combinations of
installboot and disklabel -B I can think of, both in netbsd and
quasijarus, and all lead to the same result.

Can anybody tell me the exact incantations necessary to install
the bootblocks for quasijarus0a, or does anybody who has installed
quasijarus0a have a session transcript? any idea what I might be
doing wrong?

So far I have not been able to boot any other VAX operating system
from the TUHS archive, the netbsd bootloader cannot load ultrix32m,
32v and 3bsd. I have not yet had time to try any of the other 4.x
bsds, but I assume they'd have the same problem as quasijarus0a.

I have tried ultrix-4.3 (also from the netbsd bootloader, I don't
have ultrix/vax media to do it right), but it does not work either.

If anybody can help me with this, thanks in advance

Rico Pajarola

The following transcript shows how I boot it (first the way it
fails, then the way it works):

> VAX simulator V2.9-9
> sim> show c
> VAX simulator configuration
> 
> CPU, 32768KB
> TLB, 2 units
>   TLB0, 8KW
>   TLB1, 8KW
> ROM, 128KB
> NVR, 1KB
> SYSD, 2 units
>   SYSD0
>   SYSD1
> QBA
> TTI
> TTO
> CSI
> CSO, not attached
> CLK
> PTR, address=20001F68-20001F6F, not attached
> PTP, address=20001F68-20001F6F, not attached
> LPT, address=20001F4C-20001F4F, not attached
> RQ, address=20001468-2000146B, 4 units
>   RQ0, 159334KB, attached to 4.3-quasijarus0a.rd54.dsk, write enabled, RD54
>   RQ1, 622932KB, attached to ../netbsd-vax/netbsd-vax.ra82.dsk, write enabled, RA82
>   RQ2, 409KB, not attached, write enabled, RX50
>   RQ3, 409KB, not attached, write enabled, RX50
> RL, disabled
> TS, disabled
> DZ, disabled
> sim> boot cpu
> 
> 
> KA655-B V5.3, VMB 2.7
> Performing normal system tests.
> 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
> 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
> 08..07..06..05..04..03..
> Tests completed.
> >>>boot dua0
> (BOOT/R5:0 DUA0)
> 
> 
> 
>   2..
> -DUA0
> HALT instruction, PC: 00000C1A (MOVL (R11),SP)


> >>>boot dua1
> (BOOT/R5:0 DUA1)
> 
> 
> 
>   2..
> -DUA1
>   1..0..
> 
> 
> >> NetBSD/vax boot [Aug 19 2001 05:57:49] <<
> >> Press any key to abort autoboot 3
> > boot quasijarus0a -a
> 327204+103384+130352+[29436+24084] total=0x96220
> 4.3 BSD Quasijarus UNIX #0: Sat Oct  2 22:15:38 CDT 1999
>     msokolov at luthien:/usr/src/sys/GENERIC
> real mem  = 33521664
> SYSPTSIZE limits number of buffers to 80
> avail mem = 31697920
> using 80 buffers containing 655360 bytes of memory
> MicroVAX 3000, ucode rev 6
> uda0 at uba0 csr 172150 vec 774, ipl 15
> uda0: version 3 model 3
> uda0: DMA burst size set to 4
> ra0 at uda0 slave 0: RD54, size = 311200 sectors
> ra1 at uda0 slave 1: vaxnetbsd, size = 1216665 sectors
> ra2 at uda0 slave 2: floppy
> ra3 at uda0 slave 3: floppy
> lp0 at uba0 csr 177514 vec 200, ipl 14
> root device? ra0
> WARNING: clock gained 14 days -- CHECK AND RESET THE DATE!
> erase ^?, kill ^U, intr ^C
> #

from this point on, it works as expected.


Ultrix 4.3 gives me:
> 466788+254256+177476+[36984+34990] total=0xecfa2
> machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008
> r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274
> panic: mchk
> 
> dumping to dev ffffffff, offset 0
> dump machine check 80: vap 78302077 istate1 fb000c00 istate2 c070fd pc 8004eb57 psl 41f0000
> r0=78302073, r1=0, r2=0, r3=211bd0dd, r4=22, r5=80
> panic: mchk
> 
> HALT instruction, PC: 8000165B (XFC)


From gunther at aurora.regenstrief.org  Thu May 23 07:07:28 2002
From: gunther at aurora.regenstrief.org (Gunther Schadow)
Date: Wed, 22 May 2002 16:07:28 -0500
Subject: [TUHS] simh vax and 4.3-quasijarus
References: <0205222012.AA03045@ivan.Harhan.ORG>
Message-ID: <3CEC0890.1010807@aurora.regenstrief.org>

Hi,

I found SIMH really handy as opposed to a real VAX. Was the only
way I could bring my VAX 6460 to boot Ultrix 4.5 which I only had
on a CD and the standalone kernel that came with Ultrix 4.5 didn't
support the KA64A although the normal generic Ultrix 4.5 kernel
does. So, I made a small disk installed a generic root partition
on SIMH used an uVAX-II under NetBSD to pull the disk image via
NFS to a TK50 and then booted VAX 6460 under VMS and wrote the
disk image to RA90 and off I went. I couldn't have done it without
SIMH :-)

Anyway, to your problem:


>>here's what I see, complete transcript at the end
>>
>>>>>>boot dua0
>>>>>>
>>>(BOOT/R5:0 DUA0)
>>>
>>>
>>>
>>>  2..
>>>-DUA0
>>>HALT instruction, PC: 00000C1A (MOVL (R11),SP)


this suspiciously looks as if the HALT is from SIMH not from the
VAX it simulates. There are two halt levels in SIMH, one being
the VAX halting and going into VAX console mode, the other being
SIMH halting. Are you absolutely sure that you have a proper
VAX console with SIMH? You should get normal VAX console
behavior, try a few commands and see whether you're on the right
page.

Also, be sure you have it all configured right, that you have
the right devices defined and properly associated with files
on the hosting OS etc.


>>that's obviously not what I want. I tried all combinations of
>>installboot and disklabel -B I can think of, both in netbsd and
>>quasijarus, and all lead to the same result.
>>
>>Can anybody tell me the exact incantations necessary to install
>>the bootblocks for quasijarus0a [...]
>>
> 
> This seems like a simh problem, or, more probably since you can boot That Other
> OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked
> by a simh problem. 


I would agree. What other system can you boot on SIMH?


>>Ultrix 4.3 gives me:
>>
>>>466788+254256+177476+[36984+34990] total=0xecfa2
>>>
> 
> OK, so the kernel has been loaded successfully.
> 
> 
>>>machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008
>>>r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274
>>>panic: mchk



 > Since Ultrix V4.3 perfectly supports the KA655 CPU, this again must be a case
 > of simh misemulating it.

again, your SIMH configuration may be screwed up. I definitely could
boot Ultrix 4.5.

-Gunther



-- 
Gunther Schadow, M.D., Ph.D.                    gschadow at regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistant Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org




From msokolov at ivan.Harhan.ORG  Thu May 23 06:12:55 2002
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Wed, 22 May 02 13:12:55 PDT
Subject: [TUHS] simh vax and 4.3-quasijarus
Message-ID: <0205222012.AA03045@ivan.Harhan.ORG>

Rico Pajarola <rp at servium.ch> wrote:

> I installed 4.3-quasijarus on simh [...]
> I have been unable to boot it directly from it's 'own'
> filesystem.
>
> here's what I see, complete transcript at the end
> > >>>boot dua0
> > (BOOT/R5:0 DUA0)
> > 
> > 
> > 
> >   2..
> > -DUA0
> > HALT instruction, PC: 00000C1A (MOVL (R11),SP)

My ability to help you here will be limited because you are using simh rather
than a real VAX. The real KA655 console ROM does not issue halt messages like
the above, its halt message have a different form (the one prescribed by DEC
STD 032-0, VAX Architecture Standard). The last message above does not exist on
any real VAX made by DEC.

> that's obviously not what I want. I tried all combinations of
> installboot and disklabel -B I can think of, both in netbsd and
> quasijarus, and all lead to the same result.
>
> Can anybody tell me the exact incantations necessary to install
> the bootblocks for quasijarus0a [...]

This seems like a simh problem, or, more probably since you can boot That Other
OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked
by a simh problem. You've got a halt inside VMB that happened after VMB had
successfully opened the boot device but before it accepted a valid bootblock.
What happens on a real KA655 is as follows: the console copies VMB from the
EPROM to RAM and transfers control to it, which is accompanied by the display
of 2.. on the console and on the CPU module LEDs. At that point the VAX is
unhalted, i.e., the RUN indicator on the front panel lights up. VMB thus runs
as user code and tries to perform the bootstrap. As VMB successfully opens the
boot device using its built-in drivers, it displays the device name in VMS
format on the console. Then if it finds and accepts a valid bootblock it
displays 1.. on the console and on the CPU module LEDs. Finally it transfers
control to the bootblock accompanied by 0.. display. If something goes wrong
and VMB gives up, it prints its own error message on the console and then
executes a HALT instruction to return to the console prompt. The HALT
instruction halts the VAX (the RUN indicator on the front panel goes out) and
invokes the console, which prints the halt message followed by the >>> prompt
as prescribed by DEC STD 032-0.

It looks like you are seeing VMB fail for some reason and halt, giving you the
(not compliant with DEC STD 032-0) halt message from simh. However, you are not
seeing VMB's error message which on a real KA655 will always appear before the
halt message from the console. This is a simh problem, it obviously does not
fully and properly emulate the real KA655 here. I cannot help you past this
point as I only support real VAX hardware. There is probably something wrong
with your bootblock as your emulated VAX's VMB is not accepting it while
accepting the one on DUA1 from That Other OS, but your poor emulator prevents
you from seeing what the problem is.

> So far I have not been able to boot any other VAX operating system
> from the TUHS archive, the netbsd bootloader cannot load ultrix32m,
> 32v and 3bsd.

I don't know / don't care much about That Other OS and its bootloader, but the
format of the VAX unix/vmunix kernel image and its boot interface has remained
absolutely unchanged from 32V through 4.3BSD-Quasijarus0a inclusive (but see
below about VAX model support). DEC has extended the boot interface in Ultrix,
but it's completely backward compatible: as the Ultrix bootloader starts the
kernel with a calls instruction, it passes one argument (calls $1) whereas
traditional Bell/Berkeley UNIX had zero (calls $0). A traditional kernel will
simply ignore this argument, while the Ultrix kernels checks for its presence
(thanks to the wonderful VAX architecture and its procedure call standard that
allows a procedure to determine its argument count) and lives without it if
it's absent. (That argument is a pointer to a structure with useful info,
however, and I plan to adopt this extension in 4.3BSD-Quasijarus1.)

> I have not yet had time to try any of the other 4.x
> bsds, but I assume they'd have the same problem as quasijarus0a.

4.3BSD-Quasijarus0 was the first release to support KA650/655, so don't bother
trying earlier ones. (Although you could try 4.3-Reno if that's what you like.)

> I don't
> have ultrix/vax media to do it right

You can get the complete TK50 distribution (tape images) of Ultrix V4.00 for
VAX on my FTP site ivan.Harhan.ORG in /pub/UNIX/thirdparty/Ultrix-32. I have
full sources for it there too.

> Ultrix 4.3 gives me:
> > 466788+254256+177476+[36984+34990] total=0xecfa2

OK, so the kernel has been loaded successfully.

> > machine check 82: vap 82000004 istate1 7c000c00 istate2 c070fe pc 80001c61 psl 41f0008
> > r0=8000000c, r1=8000167c, r2=0, r3=211bd0dd, r4=0, r5=dd274
> > panic: mchk

Since Ultrix V4.3 perfectly supports the KA655 CPU, this again must be a case
of simh misemulating it.

My advice to you is to get a real VAX.

MS

P.S. You may want to subscribe to the Quasijarus mailing list, send a request
to quasijarus-request at ifctfvax.Harhan.ORG.


From mrfusion at uranium.vaxpower.org  Thu May 23 08:41:45 2002
From: mrfusion at uranium.vaxpower.org (Lord Isildur)
Date: Wed, 22 May 2002 18:41:45 -0400 (EDT)
Subject: [TUHS] simh vax and 4.3-quasijarus
In-Reply-To: <3CEC0890.1010807@aurora.regenstrief.org>
Message-ID: <Pine.3.89.10205221842.A16646-0100000@uranium.vaxpower.org>

> I would agree. What other system can you boot on SIMH?

I know 4.3tahoe, netbsd, some ultrix version, and vms boot in it. 
(not to say other ultrix versions dont, but e.g. gunther has booted
ultrix under simh, i have heard many people booting vms, and i have run 
it with images dd'ed from the (running :) / and /usr of one of my 4.3t 
vaxen.) 

What is your configuration? 
isildur


From Steve.Adams at guardian-ext.Bond.edu.au  Thu May 23 16:44:46 2002
From: Steve.Adams at guardian-ext.Bond.edu.au (sadams@resumeship.com)
Date: Thu, 23 May 2002 02:44:46 -0400
Subject: [TUHS] Interview ASAP
Message-ID: <200205230644.QAA14059@guardian-ext.bond.edu.au>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20020523/e4f8c3a0/attachment.html>

From rp at servium.ch  Thu May 23 17:41:42 2002
From: rp at servium.ch (Rico Pajarola)
Date: Thu, 23 May 2002 09:41:42 +0200 (CEST)
Subject: [TUHS] Re: simh vax and 4.3-quasijarus
Message-ID: <20020523074142.18F5340EAD4@enigma.cybertime.ch>

From: Gunther Schadow <gunther at aurora.regenstrief.org>
>>>
>>>  2..
>>>-DUA0
>>>HALT instruction, PC: 00000C1A (MOVL (R11),SP)
>
>this suspiciously looks as if the HALT is from SIMH not from the
>VAX it simulates. There are two halt levels in SIMH, one being
>the VAX halting and going into VAX console mode, the other being
>SIMH halting. Are you absolutely sure that you have a proper
>VAX console with SIMH? You should get normal VAX console
>behavior, try a few commands and see whether you're on the right
>page.
At this point, I am at the simh prompt (">"). I think simh catches
the halt instruction and goes to the simh prompt when it encounters
one. I have a VAX 4000/300 at home (unfortunately it doesn't run
any of the older unixes), and when it halts, I get the >>> prompt
(differs from simh).

>Also, be sure you have it all configured right, that you have
>the right devices defined and properly associated with files
>on the hosting OS etc.
I am pretty sure that I have configured simh correctly, I verified
this by installing netbsd on the same setup, and it boots ok.

My only problem seems to be getting the bootblocks right. I have
heard that someone managed to install quasijarus0a on simh, so it
must be me somehow screwing the bootblocks.

>> This seems like a simh problem, or, more probably since you can boot That Other
>> OS successfully, a problem with your installation of 4.3BSD-Quasijarus0a masked
>> by a simh problem. 
the problem is with the bootloader only, quasijarus0a runs well once booted using
the netbsd bootloader.

>I would agree. What other system can you boot on SIMH?
only netbsd and quasijarus0a (I don't have any vms media).

thanks for your help

Rico Pajarola


From rp at servium.ch  Thu May 23 18:24:15 2002
From: rp at servium.ch (Rico Pajarola)
Date: Thu, 23 May 2002 10:24:15 +0200 (CEST)
Subject: [TUHS] simh vax and 4.3-quasijarus
Message-ID: <20020523082415.916E040EAD4@enigma.cybertime.ch>

is there anybody who has successfully installed 4.3-quasijarus on
simh, who could tell me how to install the bootblocks (I am not
completely sure that I got the disklabel right). The exact incantation
of installboot and the output of disklabel would be very helpful.

Rico Pajarola


From msokolov at ivan.Harhan.ORG  Fri May 24 01:07:13 2002
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Thu, 23 May 02 08:07:13 PDT
Subject: [TUHS] Re: simh vax and 4.3-quasijarus
Message-ID: <0205231507.AA01361@ivan.Harhan.ORG>

Rico Pajarola <rp at servium.ch> wrote:

> At this point, I am at the simh prompt (">"). I think simh catches
> the halt instruction and goes to the simh prompt when it encounters
> one. I have a VAX 4000/300 at home (unfortunately it doesn't run
> any of the older unixes), and when it halts, I get the >>> prompt
> (differs from simh).

The 4000/300 works like any other uVAX (VAX processor implemented in a single
IC) in this respect: a halt is a special exception that works like regular VAX
macrocode exceptions except that it saves the PC and the PSL in special IPRs
rather than on the stack (so that it doesn't depend on a stack), vectors to the
hardwired ROM address 20040000 rather than through SCB (so that it doesn't
depend on SCB), and MAPEN is cleared (so that it goes to the physical address
20040000 in the ROM rather than whatever that address may be virtually). The
CPU board firmware than displays the halt message and the >>> prompt as
prescribed by the VAX Architecture (DEC STD 032-0). KA650/655 works exactly the
same way.

While I haven't played with simh and don't intend to in the near future (due to
my general lack of interest in emulators), thus I don't claim to be right here,
but from your session logs it appears that simh is not doing the above uVAX
halt exception but instead it handles halts like an 11/780, by "physically"
stopping all instruction execution. That is fine and dandy, the 11/780 way is
certainly cooler, but the problem is it ain't a KA655 any more, and one should
not expect the KA655 boot ROM to work right then (and IMAO it has no right to
report the KA655 SID code either).

> I am pretty sure that I have configured simh correctly, I verified
> this by installing netbsd on the same setup, and it boots ok.

When I took a cursory look at SIMH/VAX, which consisted only of glancing at its
brief documentation, I read that the KA655 ROM image it comes with is not the
real one but hacked to work with the poor emulator. This suggests to me that
you are able to boot some OSes because Bob has gutted the (quite complicated)
KA655 console and boot logic to the bare minimum he had emulated. I wouldn't be
surprised if he hacked out the KA655 diagnostic executive almost entirely, so
that on "power-up" one goes through an absolutely minimal init sequence without
a single halt/unhalt cycle occuring (of which on a real KA655 several occur on
every power-up during diagnostics), gets to the >>> prompt, and then when
booting, runs VMB, unhalts once (the SIMH probably doesn't even know that it
unhalts, as the uVAX unhalt is simply an RFI: on real hardware it knows that
this RFI is an unhalt and lights the RUN LED because the SSC chip compares
instruction fetch addresses against the halt range and detects the unhalt, but
I doubt that SIMH emulates this), and then it all goes well (cross your fingers
three times!) never goes through a proper KA655 halt/unhalt again. But if
something goes wrong in the boot and VMB's error handler gets invoked, SIMH's
very poor man's emulation is not prepared for it.

> My only problem seems to be getting the bootblocks right. I have
> heard that someone managed to install quasijarus0a on simh, so it
> must be me somehow screwing the bootblocks.

But the rub is that because of SIMH talking the KA655 talk but not walking the
KA655 walk, you can't see what exactly is the problem with your bootblocks:
VMB's error messages aren't displayed.

MS


From msokolov at ivan.Harhan.ORG  Fri May 24 11:46:14 2002
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Thu, 23 May 02 18:46:14 PDT
Subject: [TUHS] Re: simh vax and 4.3-quasijarus
Message-ID: <0205240146.AA01856@ivan.Harhan.ORG>

I wrote:

> the uVAX unhalt is simply an RFI: on real hardware it knows that
> this RFI is an unhalt and lights the RUN LED because the SSC chip compares
> instruction fetch addresses against the halt range and detects the unhalt

Of course I meant REI. I was mixing VAX and PowerPC in my head again... That's
what happens when you try to work on too many architectures at the same time.

MS


From Bryan.Cantrill at eng.sun.com  Mon May 27 16:59:03 2002
From: Bryan.Cantrill at eng.sun.com (Bryan Cantrill)
Date: Sun, 26 May 2002 23:59:03 -0700 (PDT)
Subject: [TUHS] Memorial Day in uts
Message-ID: <200205270659.g4R6x3Kl251645@jurassic.eng.sun.com>

I recently discovered your excellent site (was pre-Lions src just recently
made available?), which prompted me to send the following mail out to my
colleagues in Solaris Kernel Development.  (Apologies in advance if you find
this annoying, superfluous or disrespectful -- I thought some might find
it interesting, if stupid.)  If there are other kernel implementors of
AT&T-derived UNIX lurking here, it would be enlightening to know what a
similar comparison yields on your baby.  (It should go without saying that
the implementation of each mentioned function has virtually no resemblance
to its V3 forebear.)  And of course, my burning question:  has none of us
changed "/* stat codes */" in proc.h?)

------8<---------------------

Subject: Memorial Day in uts
To: kernel at eng.sun.com

All,

This Memorial Day, take a moment to remember the source code that has
served in our kernel since its inception.  To this end, wander by
http://minnie.tuhs.org/UnixTree/, and pause for a moment to commemorate
these brave functions from the 101st Tapeborne -- all of which have
served continuously since August, 1973:

        bflush()        falloc()       newproc()         sched()
         bread()        getblk()         nodev()        signal()
        brelse()          getf()       nulldev()          stty()
        bwrite()          gtty()         panic()         suser()
         clock()         issig()        printf()         swtch()
        closef()        mmread()          psig()       timeout()
          core()       mmwrite()       psignal()       ufalloc()

Their compatriot structure fields include:
 
         av_back         b_flags          p_flag          u_cdir
         av_forw          b_forw          p_ppid                
          b_back           c_arg (*)      p_stat                
         b_blkno          c_func (*)      p_wchan              

(*) c_func and c_arg are notable for having survived a bonwick scorched-earth
rewrite of callouts circa 1997 -- unclear if this makes them eligible for
the Purple Heart, or if they should be considered acquited war criminals.

As for constants, B_DONE, B_ERROR, FREAD, FWRITE, and SSLEEP have all had the
same numerical value since they enlisted in 1973.  And a moment of silence
is certainly due to this line in proc.h -- a line which has not changed
so much as a character since 1973:

  /* stat codes */

And to the code ripped out in the line of duty, we say only:  "We Have Not
Forgotten."  (Of course, we usually follow that up with "Never Again.")

	- Bryan

----------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.  bmc at eng.sun.com  (650) 786-3652


From ken.beer at db.com  Tue May 28 14:24:29 2002
From: ken.beer at db.com (Ken Beer)
Date: Tue, 28 May 2002 00:24:29 -0400
Subject: [TUHS] Ken Beer/NewYork/DBNA/DeuBa is out of the office.
Message-ID: <OFF1B3FEDD.7D7641CD-ON85256BC7.001836F3-85256BC7.001836F5@db.com>

I will be out of the office starting  05/25/2002 and will not return until 06/06/2002.

I will respond to your message when I return. I will be on vacation. My manager, Venkat Jituri has my contact information.  For Equity Research issues, contact Chris Fumai.


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.




