Re: Larger dev_t

[Alan Cox]

> Another example: all the stupid pseudo-SCSI drivers that got their own
> major numbers, and wanted their very own names in /dev. They are BAD for
> the user. Install-scripts etc used to be able to just test /dev/hd[a-d]
> and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI

Sorry here I have to disagree. This is _policy_ and does not belong in the
kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of 
major/minor encoding. If you dont mind kernel based policy then devfs
with /dev/disc already sorts this out nicely.

IMHO more procfs crud is also not the answer. procfs is already poorly 
managed with arbitary and semi-random namespace. Its a beautiful example of
why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's
per device file systems solve that.

> layer made it impossible for a driver writer to be nice to the user, so
> instead they got their own major numbers.

Not deficiencies in the SCSI layer, there is no way the scsi layer can
handle high end raid controllers. In fact one of the reasons we can beat
NT with some of these controllers is because NT does exactly what you
suggest with scsi miniport driver hacks and it _sucks_. Its an ugly hack.

A 20bit minor space actually solves most of this anyway. All the drivers
taking 8 majors suddenely need only one. We go back to 1 major per raid
controller class worst case. and we just about have enough minor numbers for the
extreme S/390 configuration of 65536 DASD volumes with 16 partitions per
volume.

12:20 sounds good to me. If need be we can have extend the small allocations
space as we have with 10,* now.

Alan