Just think s/major/dev_lo/g and s/minor/dev_hi/g. This is the
represantation for a legacy protocol. Just because fat thinks
of a filename as 8+3 Linux filenames don't have to be that format.
> 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).
Umm, no. You're far to major/minor biased to realized live get a lot
sipler for use if we don't do any complicated mapping of old dev_t
to the larger dev_t. With the proper ranges we can just map it
numerically 1:1 to the new dev_t. Yes, that means it's all in one
new "major". But who cares?
-
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/