Since Linus opened for this the other day I guess I would like to
suggest it "officially":
Since glibc already runs with a 64-bit dev_t on as far as I know all
Linux platforms, which means that userspace is already taking the
performance hit, *and* since it cause it isn't murdeously obvious by
now, changing the kernel/userspace interface for this is painful as
hell, I would like to suggest that:
a) We use a 32+32 bit split for dev_t. Major zero, minor < 65536
would be reserved for compatibility with the old 16-bit dev_t; it
still leaves the zero value the "no device" entry. We could still
use major 0, minor >= 65536 as anonymous devices, or we could
switch using major 255 which has been reserved for expansion for
the past eight years.
b) In order to support NFSv2 and other filesystems which only support
a 32-bit dev_t, I suggest we stay within a (12,20)-bit range for as
long as that is practical. Note, however, that this only affect
using those filesystems for /dev, and I personally think it's not
too huge of a loss to say "well, if you use NFS for root, either
use NFSv3 or make /dev a tmpfs and extract a tarball from your
initrd."
All cases where we have to deal with a 32-bit dev_t on the wire or
on disk should use a 12+20 split.
How does this sound?
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Mar 23 2003 - 22:00:32 EST