[RFC] randomized major and minor numbers

[RFC] randomized major and minor numbers

[Carl-Daniel Hailfinger]

Hi,

IIRC it was debated during 2.5 development to make the kernel
hand out randomized major/minor numbers to better test handling
of dynamic major/minor numbers. Is there a patch available
to test?

Background: I want to make sure that userspace can handle
arbitrary device numbers for disks in my quest for a unified
/dev/diskXpY naming and numbering scheme. This would unify
all the different naming schemes (hd*, sd*, ub*, etc.),
remove arbitrary limits like 15 partitions max on SCSI disks
and achieve most of this in userspace with udev.

In the end, there would be only one block major number >256
with dynamically allocated major numbers for all disks in the
system if LANANA agrees with such a concept. Why would I
want a major >256 registered? Because that way we can make
sure the software accessing these devices can handle a large
dev_t and it doesn't only work by luck.

Comments?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] randomized major and minor numbers

[Greg KH]

On Thu, Nov 04, 2004 at 03:03:57PM +0100, Carl-Daniel Hailfinger wrote:
> Hi,
> 
> IIRC it was debated during 2.5 development to make the kernel
> hand out randomized major/minor numbers to better test handling
> of dynamic major/minor numbers. Is there a patch available
> to test?

Not yet, care to make one?  :)

Note, any such change, would only be a development aid, and not a
requirement by any means.

thanks,

greg k-h

Re: [RFC] randomized major and minor numbers

[Carl-Daniel Hailfinger]

Greg KH wrote:
> On Thu, Nov 04, 2004 at 03:03:57PM +0100, Carl-Daniel Hailfinger wrote:
> 
>>Hi,
>>
>>IIRC it was debated during 2.5 development to make the kernel
>>hand out randomized major/minor numbers to better test handling
>>of dynamic major/minor numbers. Is there a patch available
>>to test?
> 
> 
> Not yet, care to make one?  :)

Will do once I have some time.

> Note, any such change, would only be a development aid, and not a
> requirement by any means.

Of course. My intention was to have this available as a testing harness,
possibly configurable under the kernel debug options (not strictly kernel
debugging, but it can help improve the kernel).

Right now I'm not sure whether it is possible to have different drivers
serving the same block major. IIRC there was/is such a limitation, so I
would have to create a new "disk" driver first which would serve as sort
of a multiplexing driver for all block device drivers.


On another note, Joel Becker and I had a private discussion about my
suggested naming scheme and I have to agree with him that it was
suboptimal. However, my main intention was to go forward with a generic
disk access interface and not start a flamewar about naming. Naming is
policy and I'd rather leave that decision to somebody else.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/