Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!kodak!gizzmo!lazlo!galaxia!rayssdb!rayssd!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.unix.wizards
Subject: Re: is this wise?
Keywords: /dev/stdin, /dev/hosts
Message-ID: <1414@frog.UUCP>
Date: 10 May 89 20:08:00 GMT
References: <1563@auspex.auspex.com> <378@chessene.UUCP> <12765@ut-emx.UUCP>
Organization: Misanthropes-R-Us
Lines: 33

In article <12765@ut-emx.UUCP>, clyde@ut-emx.UUCP (Clyde W. Hoover) writes:
> Deja-vu!  In the old days when the ARPANET used NCP and the highest UNIX release
> was V6, (anyone remember 'smalldaemon' and 'largedaemon'?) a 
> version of the UIUC networking code worked much like that.
> Can you IMAGINE ... modifying namei to recognize "/dev/network" and not
> actually require all those files to exist?

Yes.  I can imagine that.  I can even go READ it.

MIT's CHAOSNET implementation for 2.9BSD used exactly the proposed scheme
(except that host IDs were octal numbers).  A set-uid device was treated by
namei() as the end of the pathname search, and the device open routine was
handed the remainder of the pathname string.

This migrated into UNOS (my fault, I'm afraid).  It actually turns out to
be quite useful for a number of things; for example, a proposal keeps floating
about to reduce the overloading of minor device numbers in our disk channel
interface by having the driver accept names like /dev/cc1/flop/dsqd9s512b
so that you can use any format that the floppy drive is capable of coping
with (and let's not even begin to discuss the 65536 unique SCSI target-IDs
that are potentially available).  We've not implemented this yet, since we
keep finding other ways to muddle through, but it would be handy.

Sort of a similar idea crops up in V[89] UNIX, courtesy of the file system
switch.  /proc is NOT a table of {filename, inum} pairs in a file somewhere;
the names are recognized by the lookup primitive of the /proc filesystem
handler.  Of course, getdents() on /dev/network might prove problematic... :-)

-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

	Fellow cranks!!  ...I'm not ALONE!!