That's what we already have. The problem with this (as far as I can see) is
hardware configuration changes may change the dynamic allocation, and that
is exactly what we don't want. We'd like to have some sort of way of
keeping devices where they were last seen at, or in a different, completely
deterministic place.
> I think that it's the *devices* that are the central objects here, not their
> implementation on specific SCSI channels. I don't see any reason that a dev_t
> needs to map directly to any SCSI details.
Hardware configuration changes. You muck with the SCSI bus a bit, leave a
device on or off, your configuration changes. A device crashes while the
system is unattended, the dynamic device allocation changes and the machine
runs a risk of not being able to go multiuser (or maybe not even boot).
> Each SCSI Device can refer to the
> specific bus, the driver that handles that bus, and whatever details are
> necessary to address that device.
Again, in a _non_deterministic fashion.
> I think 65536 devices of each type is probably sufficient for the moment. If
> not, we can shrink the major number a bit more. The reason 32 bits aren't
> enough in most of the suggestions I've seen is that we're trying to encode
> irrelevant and unnecessary information into the minor numbers. dev_t does not
> need to be the way of naming devices from the user's perspective.
It certainly does. I agree that once we're in multiuser mode, device assignments
become almost irrelevant. In getting to multiuser mode, though, device
assignment is essential, and having a way to refer to any device on any bus,
unambiguously, given knowledge of the partition on that device, the SCSI ID,
the controller it's on, etc., or alternately, a volume label, is damned
important.
> Leonard
So now it's time to throw out my own ideas:
/proc/scsi/dev becomes a list of names in some other format, say,
"DEC-DSP5200S" or "MATSHITA-CR-503BCQ" which are links to our current devices
in /dev/s[dtrg]*. This gives the kernel a truly deterministic handle on
devices from any point after boot. The kernel (and possibly the
bootloaders) could be adapted to accept "root=DEC-DSP5200S/a" to boot off of
/dev/sd*a (* wherever that drive happens to fall).
Or, we could come up with /proc/partitions/* which would be a list of
partition-named links, similar to the above system (but would support IDE
and other disks too, even if it is only applicable to disks). You won't
often find yourself needing access to anything but disks before multiuser
(except occasionally tapes, and you'll usually be in attendance when
operating those), so I think this would be quite sufficient.
-- Jon Pickard * 149 Olive #45 * Paso Robles CA 93446 * +1 805 2399518 * 6372F5B9 *My e-mail address is (C) 1996 and is free for non-commercial use. It is not* * to be used for solicitation or other commercial purposes of any kind. *