After looking at kdev_t and existing code some more, I think that it
should be an unsigned long.
You have understood absolutely nothing about why I introduced
kdev_t.
The main problem was boot loaders, such as the kernel boot sector which
uses a word (16-bit) to store the root device major/minor number. I
overcame this by defining kdev_t conversions which supported various
sizes of kdev_t values:
u16_to_kdev_t() converts 8-bit major/minor to 16-bit
This solution keeps most of userland, such as LILO, binary compatible.
But kdev_t is kernel-internal.
Whatever the kernel chooses is completely invisible
for user space. Its identity is hidden inside kdev_t.h,
even the rest of the kernel doesn't know.
If I boot a kernel on Friday, kdev_t is a pointer to a structure,
on the other days it is a 32-bit integer.
*Nothing* in userland depends on kdev_t.
(Well, yes, there are a few obscure ioctls that leak -
I know, don't tell me. The fact remains: userland is
independent of kernel-internal choices.)
* making kdev_t a struct, or a pointer to a struct, complicates
assignment of kdev_t values
No.
* tons of existing code stores a device number in a 32-bit var, and
passes this value into to_kdev_t() inline function
I discussed MKDEV() in my previous letter.
* making kdev_t an unsigned long allows growth and 32-bit major/minor
numbers on 64-bit platforms
Yes, but we also want to get rid of these arrays.
See, right now we have fixed arrays of length MAX_BLKDEV.
You do not want to throw away lots of memory and give these
length 65536 or so. You just want a driver_struct, and in this
structure one finds interesting things about the device, like
the blocksize and the readahead etc. And, by the way, also
the major and minor number.
Introducing kdev_t as a structure, and introducing large
device numbers are in principle independent actions.
But, by coincidence, we get the latter for free if we do
the former.
Introducing kdev_t as a structure is a kernel-internal thing.
Not very difficult. Communicating large device numbers to the
outside world, say in the stat call, is a different matter again.
I experimented a bit with kdev_t.h patches and found that a 32-bit
kdev_t was quite easy to add, and very compatible with existing code.
Yes. And making kdev_t a pointer to a structure is just as easy.
(Indeed, the code I sent in the previous letter does just that -
and it compiles and runs. Where is your problem? Efficiency?
In fact the version with device structs is faster, since all
information is localized.)
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/