Messages in this thread | | | Date | Thu, 3 Apr 2003 14:13:29 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: 64-bit kdev_t - just for playing |
| |
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
- 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/
| |