I wonder whether we are going to use 32bit or 64bit dev_t, because right now
I can still change it for sparc64 in the stat structure (all fields are LFS
capable but dev_t is right now 32bit there), after one month or two I'd have
to add new syscall like it will be needed on all 32bit ports.
Go 64bit.
It is trivial for libc headers to describe a 64bit value as
a dummy and a 32bit value, so if one should decide later that
32bit is good enough, then the 64bit value the kernel produced
will be fine. But if we decide to go 64bit then clearly 32 bits
do not suffice.
Pro 64: new types of hardware arise with hierarchical addresses.
64 bits can be 8 levels of 8 bits or 4 levels of 16 bits
Modern BIOSes use 64bits to specify a device path.
Contra 64: old C and old NFS do not handle it.
Clearly, we must use 64 bits in the filesystem and in the kernel
(in the way I described in some recent discussion). We can opt
to temporarily use glibc headers that only use the low order 32 bits,
should we wish so.
Andries
-
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/