Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: SCSI device numbering | Date | Wed, 3 Jul 1996 06:37:29 -0400 (EDT) |
| |
From: hpa@freya.yggdrasil.com (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.
|  |