lkml.org 
[lkml]   [1999]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.055 / U:1.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site