Re: SCSI device numbering (was: Re: Ideas for v2.1

Eric Youngdale (
Mon, 1 Jul 1996 11:43:20 -0400

>Actually, I've long been of the opinion that we should use more major
>numbers. It doesn't make much sense to use the same major number for
>different controllers, and I think we could use dynamic mapping of _major_
>umbers within controllers. Each controller (*) that is found gets a major
>number of its own, with some very simple algorithm (reserve najor numbers
>256-384 for SCSI devices, increment for each controller, something like

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.

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

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.

I am not trying to be negative, but just playing devil's advocate.
Splitting up the request queue into smaller lists is certainly a positive
side effect of a change like this, as it simplifies some of the
queue handling code that we have, and effectively using one major
per bus is undoubtably a logical way to divide things up.


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