Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: 64-bit kdev_t - just for playing | Date | 30 Mar 2003 12:10:43 -0800 |
| |
Followup to: <UTC200303270109.h2R19ME28410.aeb@smtp.cwi.nl> By author: Andries.Brouwer@cwi.nl In newsgroup: linux.dev.kernel > > >> Maybe I should send another patch tonight, just for playing. > > > Please, I'd like that. > > Below a random version of kdev_t.h. > (The file is smaller than the patch.) > > kdev_t is the kernel-internal representation > dev_t is the kernel idea of the user space representation > (of course glibc uses 64 bits, split up as 8+8 :-) > > kdev_t can be equal to dev_t. > > The file below completely randomly makes kdev_t > 64 bits, split up 32+32, and dev_t 32 bits, split up 12+20. >
I have a few brief questions:
a) Along all of these you have assumed that it's more efficient to have a separate type (kdev_t) for kernel-internal "decoded" device number handling, as opposed to "encoded" device number handling. At some point, however, it ends up being a struct char_dev * or struct block_dev *. How big is this gap and does it really make sense introducing a special type for it?
b) If we do have such a type, would it make more sense to have cdev_t and bdev_t, and have per-type distinction of block- versus charness?
c) If we do have such a type, any reason to have it be a "unsigned long long" (really should be u64), instead of "u32 major; u32 minor;"?
-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/
| |