Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!sun.soe.clarkson.edu!cline From: cline@sun.soe.clarkson.edu (Marshall Cline) Newsgroups: comp.unix.wizards Subject: Re: What kinds of things would you want in the GNU OS? Message-ID: Date: 7 Jun 89 21:52:58 GMT References: <19915@adm.BRL.MIL> Sender: news@sun.soe.clarkson.edu Reply-To: cline@sun.soe.clarkson.edu (Marshall Cline) Organization: Clarkson University, Postdam NY Lines: 61 In-reply-to: rbj@dsys.ncsl.nist.gov's message of 7 Jun 89 16:55:25 GMT In article <19915@adm.BRL.MIL> rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: >> From: "Greg A. Woods" >> In article <209@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy) writes: >>> In article <1989May26.224924.5293@eci386.uucp> woods@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 //, where is >the pathname as it would appear on . Local filesystems can be >remounted on //. Perhaps I'm missing the point. Do you mean that you _REQUIRE_ the "//" 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@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591