Messages in this thread | | | Date | Wed, 6 Oct 1999 21:42:54 +0100 (GMT) | From | Riley Williams <> | Subject | Re: USB device allocation |
| |
Hi Peter.
>> And one should cure the disease (too short dev_t) instead of the >> symptoms (inventing devfs).
> Ah, but devfs *does* cure the disease. (It has the distinction > of being the only such cure so far, not counting vaporware.) > If used in no-compatibility mode, it can dynamically assign > 32-bit device numbers, without any major/minor split. Are you > suggesting that someone out there has need for more than 1<<32 > device nodes?
> And before you complain that this breaks compatibility with > someone (LILO and rdev need to be taught not to hardcode root > dev numbers in), remember that a bigger kdev_t carries the same > disadvantage.
There appears to be several people claiming that a bigger kdev_t breaks compatibility with lots of programs, and I find this rather hard to understand, so can somebody explain this to me please?
In particular, please explain what's wrong with implementing a 32-bit or 64-bit kdev_t defined such that nodes where all except the bottom 16 bits are zero, it is defined as a "compatibility node"?
As an example, and assuming a 32-bit kdev_t split into 16-bit major and 16-bit minor fields, the 16-bit major 0 would be defined this way, and would be treated as being the equivalent of the current node numbers recast as a 16-bit minor with the major 0.
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/Linux/
- 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/
| |