Re: SCSI device numbering

Albert Cahalan (
Wed, 3 Jul 1996 06:37:29 -0400 (EDT)

From: (H. Peter Anvin) (2 emails)
>> 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. My guess is that for cdroms the 'partition' field would
>> be 0. For tapes, the partition field could be used for the
>> rewinding/non-rewinding part. This strikes me as a bit unclean,
>> but I could be talked into it. I need to think about this a bit
>> to see whether there are any other potential problems.
> Actually, CD-ROMs have (one or more) sessions, which can be
> very effectively treated as partitions. I would love to have a
> multisession CD-ROM where I could mount any session I wanted.
> Let's face it -- CD-ROMs are just removable, read-only disks
> with a couple of quirks.

Yes. There are CDs with real partitions (Mac at least) and
there are IDE disk changers. Uniform naming makes a partition
on a CD-ROM in an IDE disk changer have a reasonable dev_t.

> Tape drives and generic-SCSI are character devices, whereas disks and
> CD-ROM are block devices. The former we could easily distinguish by a
> bit in the minor.
>> My main objection to the dynamic major idea is that it still leaves
>> potential problems with devices being remapped to different major
>> numbers if you move controller cards around. Some utility like
>> scsidev would still be required to maintain the /dev entries that
>> correspond to the dynamic majors. If people don't mind this level
>> of inconvenience, then I have no problem with it, but I thought the
>> point of this exercise was to try and see whether we could completely
>> get away from dynamic assignment of device numbers.
> Let's face it... we'll never get people to actually use *device
> names* that incorporate bus information; they are simply too long.
> On Solaris, which has such names, *everyone* uses the dynamically
> assigned "short" equivalent (the controller part is dynamic.)

I'd use 5-05--04.disk I think. (with '-' for n/a bits)

The primary winners are:

Kernel hackers asked to decode something. The kernel can dump hex
device numbers and they will still be very easy to read.

People with large/unstable systems who will use the formal names.

Programs like scsidev that assign volume labels at boot.

>> Also, there are some people who would like to have one common
>> major number for *all* cdrom drives on the system (ide, scsi, etc).
>> A top level driver would essentially dispatch through a table down
>> to whatever the appropriate driver is to do the job. Dynamic majors
>> take us further from this, although a sort of virtual device driver
>> would probably also do the job here.
> The people that call for that are basically the ones that want all
> CD-ROMs on the same major (i.e. /dev/cdrom would be a bona fide
> device.) I personally think it is useless -- that can be done by a
> boot script if desired -- but there probably should be a uniform way
> to find which devices correspond to actual CD-ROM, tape etc. devices.

There could be an alias for the first CD-ROM detected, perhaps with
the old 16-bit compatibility numbers. It would be useful for install
disks at least and convenient too.

>>> Purpose Bits Normal Extreme
>>> controller 4 <= 1 2
>>> bus 4 == 0 1
> Extreme known is 3, actually.
>>> device 8 <= 2 4
>>> lun 8 == 0 3
>>> partition 4 <= 3 4
> This is inadequate. The 4-bit partition limit in SCSI has shown
> too restrictive.

I did leave 4 extra bits. I'd prefer to keep them reserved, but they
could be used for partitioning. I can't see any need to partition a
disk that way, but it might be useful for odd CD-ROMs. Using those
bits would do undesirable things: either block devices become 8:24
or "bus" and "device" get swapped.

> However, since Linus is suggesting using the major for the
> controller (a very good idea, IMHO) 12+20 should be enough.

That I believe is about the same thing as getting rid of the
major:minor number concept for block devices, which you did
not like. What is the difference? Either way you look at dev_t
as a number of bits you can allocate various ways.