No, it is sufficient for everything, including really weird
SCSI adapters. Using nibble boundries (for nice hex output),
dev_t can be split as follows:
Purpose Bits Normal Extreme
controller 4 <= 1 2
bus 4 == 0 1
device 8 <= 2 4
lun 8 == 0 3
partition 4 <= 3 4
Note that the number of bits allowed is far more than normally
needed and is sufficient for every system reported to the kernel
list. The extra 4 bits can be left reserved or used for the
(rather artificial IMHO) distinction between disk and CD or
whatever. You can call part of that "major number" and part of
it "minor number" but it really doesn't make a difference for
block devices.
> This is why I wanted this issue carefully discussed before we
> actually do any coding. I know that lots of people don't like
> dynamic mapping of minors to devices, and I don't yet have a
> feel as to whether people will accept scsidev as a permenant
> solution or not.
People actually like to control partitions by volume label.
That is dynamic but not quite so random when hardware fails.
Using the 4 extra bits from above, we can do this:
0 old device number
1 new fixed device number (includes SCSI, IDE, md, floppy...)
2 dynamic number set up by user program via block offsets
3 loopback, proc, nfs
4-f reserved
> A 64 bit dev_t presents it's own problems of course,
> but I just wanted to make sure that we are not forgetting
> why this discussion got started in the first place.
64-bit dev_t has many problems and few benefits. It is not
good for backward compatibility, seems to break POSIX unless
"long" becomes 64-bit, and it too much data to haul around.