Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!spdcc!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.unix.i386
Subject: Re: questions about ISC 386/ix
Keywords: NFS & floppies, NFS & root, /lib/idcpp
Message-ID: <1990Jan6.220311.3303@esegue.segue.boston.ma.us>
Date: 6 Jan 90 22:03:11 GMT
References: <42@guug.UUCP> <1990Jan6.114222.2572@virtech.uucp>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 24

In article <1990Jan6.114222.2572@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>NFS, as part of its basic design, does not support the use of 
>device files accross a mounted file system.  I think this is probably
>due to the fact that NFS is OS independent ...

No it's because NFS is stateless, which means that any NFS call has to
be idempotent, and in general writing the same block of data to a device
twice means that you get two copies of the data, not (as on a disk) that
the same data get written to the same place twice.  The stateless design
of NFS has been widely debated and is unlikely to be fixed anytime soon.

>[idcpp and idcomp] are special versions of the compiler and c-preprocessor
>that are used to rebuild the kernel.  ...  The slight difference in size is
>due to some changes that make it hard (if not impossible) to use them as a
>real compiler if you did not buy the development system.

idcpp, idcomp, idld, and idas are actually just the same as their development
system equivalents, and if you wrapped a suitable shell script around them
you'd have a working C compiler.  You don't get include files, startup code,
or a C library, so it's far from adequate for program development.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."