On Thu, 9 Jan 1997, John F. Woods wrote:

> [Note:  if the reader tends to respond to new design ideas with "that's not
> how we did it when computers ran on STEAM!", just skip the next two
> paragraphs.  Note that I will confess to that reaction on more than one
> occasion.]

Part of that problem might be that this is BSD, which spearheaded the
change from waterwheels to steam in the first place! ;-)

> (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.

As an aside, I though of a solution to the latter problem (partition
count). If we pick a special device type, and a special name (say SCSI
hard disks), we can glean the partition #'s at boot. The special name is
the name of the first partition on the second unit. For SCSI, it's sd1a.
We boot up, and the kernel goes along quite happily. At one point in boot,
it goes out and looks at /dev/special_name (/dev/sd1a here). If it doesn't
find it, the kernel can print an error about a missing device (did we
build devices this install?), and go with a default value. If it finds the
device, it can learn the # of partitions, and change things accordingly.
The thought is that at this point, there's only one dev_t pointing to mass
storage (assuming hard disk boot), root_device. If it's an hd, just
re-compute it. Then change a global setting the # of partitions in use.

Then, to switch from 8 to 16 partitions, just re-build devices.

In principle, there could be different partition counts on different
device classes (like 8 for wdX and 16 for sdX), but as I looked at that,
it'd be gross as we then need to store the count in a group variable, and
(the bad part), hack on many parts of the code. Maybe it's not too bad,
but I don't have time right now, so...

> 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 called the portal fs, and it's in there (though not a standard
option).

Take care,

Bill