Messages in this thread | | | Date | Sun, 30 May 1999 16:55:51 +0100 (GMT) | From | Riley Williams <> | Subject | Re: Migrating to larger numbers |
| |
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/
| |