On Mon, 14 Apr 2003, Joel Becker wrote:
>
> On Mon, Apr 14, 2003 at 12:45:36AM +0200, Andries.Brouwer@cwi.nl wrote:
> > The structure here is 8+8, except when more bits are
> > present, in which case it is 16+16, except when more bits
> > are present, in which case it is 32+32.
>
> Why complicate things? Is it that bad? We'd all have to know
> about the mess when dealing with userspace.
Well, the thing is, we absolutely _do_ need to have the 8+8 split, in
order to make old devices look the same old way for old binaries.
And the 32+32 split is what the new maximum would be, so ..
The 16+16 split is not strictly necessary, but Andries pointed out to me
that there are filesystems etc external storage that only support a 32-bit
opaque dev_t, so we'd need to marshall the device number _some_ way for
them anyway, and having a standard way to do that is better than having
everybody come up with their own variations.
(My prefernce for the 32-bit version would be 12+20 bits, but it's not a
very strong one, and it doesn't really matter for the kernel proper, so I
think Andries who has been tirelessly working on this for five years or
more gets the final say on it).
Linus
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:32 EST