Larger dev_t and major/minor split

[H. Peter Anvin]

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
-- 
<[e-mail]> at work, <[e-mail]> 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