Oh, the split has huge meaning inside the kernel. We split the number
every time we open the device, and use that split to look up the result.
There's another issue, though, which may or may not be a good thing. If we
split and re-create the device number, that will always force the "dev_t"
to be in "canonical form", ie if the major and minor both fit in 8 bits,
then we will always fit the whole dev_t in 16 bits.
This shows up as a difference in the two approaches: if you consider the
user-supplied number as a unsplit binary "dev_t", then the user can supply
a 64-bit number like 0x00000001000000001, and we will actually use that as
the dev_t. However, if we split it up, and the user supplies <1,1>, then
we will always generate 0x0000000000000101 as the 64-bit dev_t, and there
is never any way to generate the "non-canonical" form.
Does it matter? Probably not. I actually think it's slightly preferable to
alway shave things in the canonical form, and the networked filesystems
will generally canonicalize it anyway since they usually split it up into
major/minor. But it _is_ potentially a user-visible difference.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/