Re: 64-bit kdev_t - just for playing

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 2 Apr 2003, Badari Pulavarty wrote:

> (ii) We need to worry about backward compatibility. For example:
> 17th disk used to have <65, 0>. Now its major, minor is <8, 256>.
> So /dev/ entires need to be re-created to match these, everytime
> you reboot 2.4/2.5 etc. Greg KH udev might fix this for us. 

I expected something like this. As soon as we want to maintain 
compatibility it can get quite ugly.
I would prefer to leave the dev_t range below 0x10000 unchanged for 2.6 
(this means in the kernel the minor bits stay at 8) and new dev_t entries 
a created dynamically. Work which is currently still done in sd.c (e.g. 
numbering/naming) can be incrementally moved to the generic code and 
during 2.7 it can be dropped from sd.c. This way other drivers can 
automatically benefit from this and don't have to reproduce the hacks 
done in sd.c. Also if someone wants more partitions it would be a simple 
switch in sd.c and all dev_t numbers are allocated dynamically.

I am really interested why nobody wants to do now that small deciding step 
to use dynamic dev_t numbers. Everyone agrees that we want to use dynamic 
numbers, but almost everyone wants to hold on to static dev_t numbers. 
What will be the next step after enlarging dev_t? Playing around with the 
major/minor split will not help in the long term and only creates new 
problems. On the other hand at this point it's trivial now to maintain 
compability for old device numbers and create and use dynamic numbers.

bye, Roman