Messages in this thread |  | | Date | Tue, 2 Jul 1996 01:06:22 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
Date: Tue, 2 Jul 1996 10:33:47 +0300 (EET DST) From: Linus Torvalds <torvalds@cs.Helsinki.FI>
On Mon, 1 Jul 1996, Leonard N. Zubkoff wrote: > > 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?
This wouldn't be a "dev_t" issue: as far as the _rest_ of the kernel is concerned, dev_t is just a 32-bit number. That goes without saying: I will totally ignore any patches that try to force any "regular" stuff on the device numbers.
Who suggested otherwise?
What I mean above is just what the SCSI drivers would use _internally_. External to the SCSI drivers, nothing even knows or cares..
(We do want some kind of SCSI rules for the minor numbers, because we want the device numbers to at least look _similar_ even if we change controllers. But this is really internal to SCSI, not a "kernel" issue per se).
No, I want the user visible names to remain the same.
> 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
NO! You seem to expect the kernel to actually care. The kernel should _not_ care at all about the actual layout of the device numbers. If some laser-guided-missile driver wants to use the 20 bit minor number for targeting information, it can do so. The kernel doesn't care.
Agreed.
We're discussing only how the _internals_ of the SCSI layer decode the number it gets passed. For the rest of the kernel, there just needs to be some simple interface to get some specific information, for example something like:
Sorry if I was unclear. I was also discussing only how the SCSI subsystem would interpret the minor number. My description above was only meant to argue that the minor portion should be completely dynamic rather than being based on bus/target/lun. I don't see why you interpreted my proposal in a completely different way from your own.
HOWEVER, within the SCSI subsystem we _do_ need to have some rules, because a user that changes his SCSI controller from a NCR controller to a BusLogic controller does _not_ want his /dev setup to change: his disks didn't change. So for SCSI it makes sense to make some rules for how the drivers should interpret the minor numbers.
Agreed. that's why I want the objects the user talks about to be named symbolically, not based on their location in the system.
dev_t _IS_ the way of naming devices when it comes to the kernel. There simply _is_ no other naming. The fact that you can then do stuff like
mknod b 256 0x010101 /dev/scsi/id1lun1part1
or whatever is irrelevant (although that also needs to be standardized, but that is no longer a kernel issue). The same goes for the names you suggested (/dev/scsi/DEC_RRD4 or whatever) - those can be generated on-the-fly at boot time. But when it comes to the kernel, all of this is irrelevant, and the only thing that means anything is the device number.
What I'm suggesting is that I think this whole method of making fixed entries in /dev which map to fixed (major,minor) pairs is unnecessary. I have no reason to talk about devices that the kernel has not recognized. Why not have entries of the form /proc/scsi/disk/DEC_RRD4 which have the correct dev_t dynamically assigned whenever the device is recognized?
The whole idea of /proc/dev and completely dynamic (major,minor) assignments has been discussed before, and I recall there were relatively few problems with it. Am I missing something fundamental here?
Leonard
|  |