Actually, we still do it for both block _and_ character devices.
Look at "nfs*xdr.c" to see what's up.
In other words, that split is definitely not virtual. It's a real thing
with real visibility for users.
The fact that the kernel internally has generalized it away doesn't
matter. Any kernel virtualization of the number still _has_ to account for
the fact that it's a real thing.
Put another way:
0x0000000000000101
_has_ to open the same file as
0x0000000100000001
because otherwise the kernel virtualization is broken (since they will
look the same to a user, and they will end up being written to disk the
same way).
Thus any code that only looks at 64-bit dev_t without taking this into
account is BUGGY.
One way to avoid the bug is to always keep all dev_t numbers in "canonical
format". Which happens automatically if the interface is <major, minor>
rather than a 64-bit blob.
I personally think that anything that uses "dev_t" in _any_ other way than
<major,minor> is fundamentally broken.
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/