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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/