lkml.org 
[lkml]   [1996]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


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