On Thu, 20 Jun 1996 19:00:16 -0400 (EDT), "Andrew E. Mileski"
<aem@nic.ott.hookup.net> said:
>> Note that with the current system, there can be a maximum of 16 disk
>> drives (since 16 * 16 partitions = 256 = max minor number). Clearly a larger
>> dev_t is needed, no matter how we do it. We need to somehow agree on how
>> large this needs to be, and *then* we need to fix the filesystems so that
>> they store a dev_t that is this large.
> Personally I find moving to a 64-bit (or whatever) dev_t a silly issue
> to squabble over. Just do it already! :-) If we need a new fs type
> like ext3, then LET'S GET ON WITH IT! Sheesh! :-)
Easy to do. Dead easy. Trivial, a two-liner, not worth losing sleep
over. As of linux-2.0.0, ext2fs even has dynamic revisions built in,
so we can mix and match 16- and (say) 64-bit dev_t filesystems in a
way which won't confuse the current kernels.
We've talked about this before. The trouble is that it is NOT a
filesystem issue, it's a kernel/libc API issue, and _that_ is tricky.
Nobody has yet been brave enough to tackle it.
Think about it. We need a new mknod(), new stat(), basically
replacing every system call which uses a 16bit dev_t. We need a new
libc which incorporates the new dev_t. _Then_ we need to recompile
every binary on your entire system which looks at dev_t. And the hard
part is that you need to do it in such a way that every possible
combination of 16/64bit libc and kernel work perfectly.
This is not an impossible task, but it's ugly. What we really need is
to synchronise libc and kernel updates for this kind of change.
libc-6 and linux-2.2, say. The kernel will have to provide the older,
short-dev ABI for a long time, but we can still mandate that the new
libc requires a newer kernel.
The only real alternative is the current scheme of rewriting things at
boot time, and that's still a bit of a problem if the boot disk itself
gets renumbered.