Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: possible SCSI device numbering solution | Date | Thu, 27 Jun 1996 01:44:00 -0400 (EDT) |
| |
>> The major number is useful for character devices, which can be >> split 12:20. For block devices, a block device is just a block >> device. If you just need a major number to fill some software >> "need", then just make it 0 for all block devices. > > Huh? The major number is the pointer to the driver; this has to be > encoded one way or the other, and it might as well be done uniformly > and efficiently. I'd go for 12:20 if it is deemed enough (which I am > not really sure about), but dropping the major is a ludicrous idea.
Not at all. Right now there is one major for all the different types of SCSI hardware. That can be extended to IDE, ramdisk, and other hardware without trouble. I'll explain how last.
------
Why 64-bit is bad: POSIX requires that dev_t be an arithmetic type. It would be _hard_ to make long 64-bit on i386 Linux now, so 64 bits would mean using "long long". Unfortunately, that breaks ANSI C (and thus POSIX?). You won't be able to use "gcc -ansi -pedantic-errors" or the bcc compiler. 64-bit dev_t messes up the alignment of "struct stat" (and others?), which would make backward compatibility harder.
Why asymmetric dev_t is OK: Note that dev_t need not be symmetric. HP-UX uses 8:24 and SysV uses 14:18, so 12:20 (which is on a nibble boundry for readable hex output) would be great. Tar is known to support 32-bit dev_t.
Why block devices can be flat 32-bit: Block devices don't really need a major number because they are all the same sort of thing, plus/minus a few IOCTLS. Character devices are often radically different, so they need major numbers.
Block devices can have dev_t bits allocated like this: 4 controller 4 bus 8 device 8 lun 4 partition That fits into 32 bits on nibble boundries with 4 bits extra. Put them wherever, maybe allow 255 partitions or find some interesting use.
------
Now, you wanted to know how to find the driver.
Simple method: You get 4 bits to identify the controller card. Use that as an index into a tiny table to get the driver needed for the card. The 4 extra bits can be used to differentiate between disks and CD-ROM if it is really needed.
Sick method: Use a hash table. This makes sparse numbers somewhat easy.
Fancy (better? worse?) method: Use a 16-way tree (max depth of 7). I would make it 16-way so that it matches up with the block device number allocation, is not irregular, and does not get too deep. If you start from "controller" it will have very few nodes, each of which is only 16*sizeof(void *) bytes. My system with IDE disk, SCSI CD-ROM, ramdisk, SCSI Zip drive, and floppy would require 23 nodes. Here's my tree:
scsi0 bus0 zip device ID (first nibble) zip device ID (second nibble) lun0 (first nibble) lun0 (second nibble) partitions cdrom device ID (first nibble) cdrom device ID (second nibble) lun0 (first nibble) lun0 (second nibble) partitions ide0 bus0 unused master/slave unused unused partitions ram unused unused unused unused unused partitions
|  |