lkml.org 
[lkml]   [1996]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: possible SCSI device numbering solution
Date
>> 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



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