Re: Migrating to larger numbers

Riley Williams (rhw@MemAlpha.CX)
Sun, 30 May 1999 16:55:51 +0100 (GMT)


Hi Peter.

>>>> 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.

It definately relies on the major 0 and minor >255 being invalid
device numbers, as suchlike combinations will be misinterpreted if
they're valid.

>> 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.

> And so how do you distinguish between (0,2000) and (7,208)?

Presumably by restricting valid devices with major 0 to have minor
numbers below 256, thus making (0,2000) an invalid combination...

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html

-
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/