🚀 go-pugleaf

mea culpa! The code in if_ether.c implementing a RARP capability in the
kernel in Celerity UNIX field release 3.4.77 is not, and was not intended
to be, a general purpose implementation. It was included as a consequence
of some diskless Sun work I have been doing and became part of the release
by accident. It stayed part of the release because it wasn't supposed to
do any harm.  My apologies for the difficulty it caused. Using my highly
developed 20/20 hindsight, I rather wish it hadn't gone out. 

We became aware of the problem within a few days of the first installations
of 3.4.77 and we quickly released 3.4.78 with the "feature" (rhymes with
creature) disabled and distributed the corrected release to the complaining
sites.

It has always been our intention to implement and release a RARP capability
functionally equivalent to Sun's, including /etc/ethers.

An additional issue disclosed by this problem is the potential confusion
in identifying release levels for source-licensed customers. The RARP
problem existed in 3.4.77, was corrected in 3.4.78 and was reported on
the net as being in 3.4.88. We haven't gotten to 3.4.88 yet!
To avoid this confusion, I would suggest that source-license holders
adopt the convention of naming their kernels as:
'local-orgination.celerity-release-level.local-release-level',
e.g., vmunix.rutgers.3.4.77.88. This may be accomplished by setting the
'version' file in the root of the source directory to the string;

			rutgers 3.4.77 88

The last field in the 'version' file is incremented by the script, 'newvers.sh'
each time a build is done, so subsequent builds will have an ascending
revision number. If you want to change the punctuation, take a look at
'newvrs.sh'.



Ron McDaniels

CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron
"Yes, my Precious. . . we hates them socket(2)eses!"