What kinds of things would you want in the GNU OS?

[Marshall Cline]

In article <19915 at adm.BRL.MIL> rbj at dsys.ncsl.nist.gov (Root Boy Jim) writes:
>> From: "Greg A. Woods" <woods at eci386.uucp>
>> In article <209 at sopwith.UUCP> snoopy at sopwith.UUCP (Snoopy) writes:
>>> In article <1989May26.224924.5293 at eci386.uucp> woods at eci386.UUCP (That's ME) writes:
>>>> Second, a leading '//' with a special meaning is a tremendous KLUDGE!
>>>> It's even worse than "machine_A:/"!
>>> 
>>> Nope, sorry, // is a small kludge, and machine_A:/ is the tremendous kludge.
>>> Your syntax attaches special to another character.  With the // syntax,
>>> the special chars remain limited to / and null.
>> I see '//' as a huge kludge, 'cause it special-cases the meaning
>> of two consecutive slashes when they appear at the beginning of a
>> line.  This goes directly against the understood meaning of
>> consecutive slashes (i.e. scrunch them into one slash).
>Agreed. It is too easy to generate consecutive `/'s by accident,
>and I would prefer that they map to just one as they do now.

Also agreed.  '//' is a huge kludge.  Such as when you have a list of
directories for something (a la $PATH).  The natural thing to do is
snatch a directory from the $PATH, append '/desired.filename', and
see if you can 'access()' that file, then go back & snatch another
directory, etc.  The problem is: What if one of the desired directories
is '/'.  Then you append another '/', creating the proposed "magic
double slash" situation.  (Obviously you can check, but it's much
easier to have the kernel coalesce adjacent slashes).

[...deleted stuff...]
>> I want to be able to put
>> directory hierarchies anywhere I please, whether they are on a
>> remote machine, or local.  That's part of what network tranparency
>> for filesystems is all about.  The meaning of "mounting a
>> filesystem" should be exactly the same, be it a local mount of a
>> physically local disk, or a remote mount of a filesystem
>> advertised to the network.
>I disagree here. I feel that they should be mounted in a standard place.
>We use NFS here, and are considering the following scheme.
>Every file should be accessible via /<host>/<path>, where <path> is
>the pathname as it would appear on <host>. Local filesystems can be
>remounted on /<name_of_local_host>/<path>.

Perhaps I'm missing the point.  Do you mean that you _REQUIRE_ the
"/<host>/<path>" situation, or are you _SUGGESTING_ it?  If "require",
seems you're putting too much policy into the kernel.  Ought we not
to desire a clean separation between Mechanism and Policy?  That's
what I like about the Un*x FS: there are only *2* special chars:
'/' and '\0'.  ALL other chars are treated equally by the Kernel
(naturally the shell enforces a bit more policy, but using a
particular shell is my choice).  The point is: the Kernel provides
as much mechanism as possible, but as little policy as possible.

Would we agree that Security concerns are exceptions to this?
Ie: Security is clearly a _policy_ issue, right??
Yet it appears[?] to belong in the Kernel, right??

Marshall
--
	________________________________________________________________
	Marshall P. Cline	ARPA:	cline at sun.soe.clarkson.edu
	ECE Department		UseNet:	uunet!sun.soe.clarkson.edu!cline
	Clarkson University	BitNet:	BH0W at CLUTX
	Potsdam, NY  13676	AT&T:	(315) 268-6591