lkml.org 
[lkml]   [1996]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: SCSI device numbering (was: Re: Ideas for v2.1
>> 	If you suggesting that we use one common major number for every
>> device on a given bus, then we need to decide how we assign minor numbers
>in
>> light of the fact that we can have a mix of disk, tape, cdrom and generic
>> device nodes trying to use the same major number.
>
>3 bits for bus number, 3 bits for subsystem type on the major number?
>With a 12/20 bit major, that's 6 bits gone which is quite acceptable,
>and it encapsulates both the bus number and the major type of device
>in the major device number.

This is getting real tight. The scsi ID can now be from 0-63,
and as I recall the LUN can go from 0 to 127 in some implementations.
For disks, we need 4 bits for partition ID, so this leaves at most 3
bits leftover. Use up 2 bits so we can identify device type, and
we then have 1 leftover. If we use these now, we have absolutely no room
leftover for any possible future expansion.

The only way I can see this working is if we say that each *bus*
gets it's own major number. If a controller drives 3 busses, then we
allocate 3 majors. This has problems of it's own, but that's about the only
way you will get the numbers to fit in a 12/20 scheme and have a fixed
mapping.

>Now, the latter is a definite possibility; we can imagine a scheme
>where we label the minor number with some unique ID encoded into every
>ext2fs filesystem. However, that still loses if we are looking at DOS
>partitions, and it doesn't help at all if we only have removable media
>devices on the controller. It probably introduces more complexity
>than it's worth.

This is why I think we should use an ASCII based volume label.
Many existing filesystems already support this (i.e. DOS, iso9660).

>Given the above argument, I really think that we can consider the
>controller number pretty much static information. This is especially
>true if, instead of just enumerating the controllers in some arbitrary
>order, we encode their major numbers using some unique characteristic
>such as their IRQ number (for ISA devices) or their PCI bus address
>for PCI adapters. This really will be static over removal of
>controllers (although not over moving of controllers in the PCI case,
>or reconfiguration of the adapter in the ISA case).

To encode a slot number, you need somewhere in the neighborhood of
8 to 16 bits. For this we really need 64 bit dev_t (this is how we got
started on this in the first place).

>> Some utility like scsidev would still be required to maintain the
>> /dev entries that correspond to the dynamic majors.
>
>In the most general case, even this won't be sufficient; user
>intervention will simply be necessary.

Note that when scsidev creates aliases, it does have the ability to
query and match based upon all sorts of things (including device serial
number, for those devices that support it). If ext2 were to support a
volume label, we could also use that as something we could match against.

>- We need an easy way for an installation script to
>interrogate the kernel for probed devices and to return the wide dev_t
>for each identified device.

This is more or less exactly what scsidev does now. The only
difference is that it creates SVr4 like device nodes and attaches them with
the correct minor numbers, using the current dynamic mapping of minors.

Eric

--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."


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