> > dev_t: 32 bits minimum, suggest 64 bits
>
> > Recall that uid_t, gid_t and dev_t both have -1 (0xffff) reserved
> > in a 16-bit environment;
>
> This suggests a particular way of going to a larger dev_t.
>
> I have been using (and am using a kernel like this right now):
>
> static inline kdev_t to_kdev_t(dev_t dev)
> {
> int major, minor;
>
> major = (dev >> 32);
> if (!major) {
> major = (dev >> 16);
> if (!major) {
> major = (dev >> 8);
> minor = (dev & 0xff);
> } else
> minor = (dev & 0xffff);
> } else
> minor = (dev & 0xffffffff);
>
> return MKDEV(major, minor);
> }
>
> I am not aware of any disadvantages of this system,
> although, now that I think about it, the fact that
> multiple representations yield the same (major,minor)
> has both advantages and disadvantages.
> So far I have not encountered real problems.
A much worse error is that it relies on zero, not -1. Zero is not a
reserved device number; in fact, it has special meaning.
Hmm. I think I disagree.
The above code does not rely on any particular number.
It just says that if the device number fits into 16 bits
then it is partitioned into major and minor in a particular way,
and if not it is partitioned in some other way.
Since for almost everybody all device numbers today do fit
into 16 bits this is fully compatible with all we have now.
There is no conflict with 0 (no device).
There is no conflict either with the present dynamically
generated device numbers, but of course if we want more of
those another major is required.
The nice part of this scheme is that one can change one's mind
about the size of dev_t (from 16 to 32 to 64 bits) without changing
what is on disk and without changing well-known device numbers.
A rigid 64=32+32 scheme would cause /dev/sda3 (major=8 minor=3)
to get a different device number.
Note that mknod requires major,minor and ls shows major,minor
but stat only yields a dev_t, and in reality there is no way
for user space to divide a dev_t up into major,minor.
As a final remark, look at the code in fs/isofs/rock.c.
By some coincidence my scheme is what the Rock Ridge standard
prescribes.
Of course many other schemes are usable as well - but I think
this is just fine.
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/