>> Though luck. Then you must redesign the kernel's guts, and a
>> largeish part of userspace. And recompile everything with
>> another way of handling devices, be it 64 bit dev_t's or some
>> other scheme. BTW, the work for enabling larger dev_t's has been
>> done a long time ago (2.1 something, or even much earlier).
>> AFAIU, glibc is also prepared for a larger dev_t. The big
>> problem is doing it, as it will break _everything_.
> Actually, it won't break *everything*; since the user-mode side
> has already been prepared, it's only an kernel issue, and the
> number of places it breaks will be large, but not impossible to
> do. I suspect a number of device drivers won't be affected at
> all --- all it requires is that the subsystem be written (or
> rewritten) to use proper macros.
> I think the main problem is that it's grunt work that no one has
> volunteered to go and do it. It's not particularly hard, it's
> just not particularly uplifting.
Would there be any objection to my volunteering to do it?
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. |
+----------------------------------------------------------------------+
-
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/