> Date: Thu, 09 Jan 1997 10:17:34 -0500
> From: "John F. Woods" <jfw@jfwhome.funhouse.com>
> 
> (One potential solution, of course, is to abandon device numbers entirely
> and instead pass the entryname down into the open routine; a lot of work,
> but it eliminates the table-version skew problem.  Of course, then you *can't*
> call your root device /dev/bert (perhaps you can if it's a symlink, since the
> extracted "real" name of the device would be available).  This also gets
> rid of the problem of being unable to increase the number of partitions on
> a disk drive owing to the minor device bit partitioning scheme.

lots of stuff depends (or may implicitly depend) on devices being tied
to an inode, particularly locking semantics. You can get yourself into
trouble by creating extra inodes for the same dev entry, so I'm *sure*
you'll get yourself into trouble by having too few :)

Once you've created an inode, by whatever form, you might as well go
the whole hog and create the filesystem.

Now, here's a counter-example: HP's JetDirect software creates lots of
copies of /dev/null, one for each print queue, and uses that as the
device for the print spooler to lock against for the queue, so that
print queues do not have to lock against eachother. It does a lot of
other bogus stuff, too, but the point is that this is another case of
useful semantics that a putative devfs should probably cater for.

> If you think that's a hack, it gets worse:  when I was at MIT, the V7 CHAOSNET
> implementation special cased namei to not merely make the entryname available
> to the driver, but to be willing to *stop* parsing a pathname in the middle if
> it hit a suitable driver, passing the entire rest of the pathname into the
> open routine; thus you could open a telnet connection with
> "/dev/chaos/223/TELNET" (approximately; this was 18 years ago, and I'm doing
> this from memory).  While you may think it grotesque to have parsing routines
> in the kernel (well, OTHER parsing routines besides namei), the ability to
> create simple network tools with "cat" was a wonder.  [I then borrowed that
> idea for UNOS, and even managed to preserve it after rearchitecting the
> filesystem code to implement a vnode layer.] )

It's just that wonder that makes me so annoyed that such things aren't
the way things were done from the start.  Such things should be there
and available, they're intuitive and exploit the power of the
interface to its fullest - they shouldn't be a cause for wonder. See
some other comments on the "everything is a file" philosophy I made
elsewhere in this thread.

We have this ability, by the way, with portalfs.

> It occurred to me that even with the simple autoconstructed /dev/ scheme,
> you still have an easy way out:  build your own /dev/ filesystem in a disk
> file (with the vnode driver), and then modify /etc/rc to mount your
> customized /dev/ over the constructed /dev/.  This *does* rely on the
> autoconstructed /dev/ containing a correct /dev/vnd0a, of course -- but
> it *will*, that's the whole point.

Right.

--
Dan.