lkml.org 
[lkml]   [1996]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SCSI device numbering (was: Re: Ideas for v2.1
Date
Quoth Leonard N. Zubkoff:
>
> Date: Tue, 2 Jul 1996 08:15:29 +0300 (EET DST)
> From: Linus Torvalds <torvalds@cs.Helsinki.FI>
>
> So something like this:
> - one major number for each SCSI bus (= usually one controller)
> - 4 (8?) bits SCSI ID
> - 7 bits SCSI LUN
> - 4 bits partition information
> - ???
>
> Yuk. Why should the dev_t need to encode these subsystem specific details?
> I'd much rather see:
>
> - 12 bits for the major number of each device type pretty much as we
> have now.
> (device types are the things that have a common set of properties)
> - 16 bits for an index into a dynamically allocated dense array of
> pointers to objects of that type
> - 4 bits for partition information or other specialization

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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.089 / U:2.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site