On Thu, Mar 22, 2007 at 06:50:00PM -0400, Robert P. J. Day wrote: > On Thu, 22 Mar 2007, Greg KH wrote: > > > On Thu, Mar 22, 2007 at 06:20:04PM -0400, Robert P. J. Day wrote: > > > > ... i'm wondering if i should be nervous about > > > the inconsistent definitions of the macros in kdev_t.h: > > > > > > ... > > > #ifdef __KERNEL__ > > > #define MINORBITS 20 > > > #define MINORMASK ((1U << MINORBITS) - 1) > > > > > > #define MAJOR(dev) ((unsigned int) ((dev) >> MINORBITS)) > > > #define MINOR(dev) ((unsigned int) ((dev) & MINORMASK)) > > > #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) > > > ... > > > #else /* __KERNEL__ */ > > > > > > /* > > > Some programs want their definitions of MAJOR and MINOR and MKDEV > > > from the kernel sources. These must be the externally visible ones. > > > */ > > > #define MAJOR(dev) ((dev)>>8) > > > #define MINOR(dev) ((dev) & 0xff) > > > #define MKDEV(ma,mi) ((ma)<<8 | (mi)) > > > #endif /* __KERNEL__ */ > > > ... > > > > > > so the definition of MAJOR() and MINOR() in kernel space is based on > > > a 12/20 split of major/minor device number, while the *user* space > > > definitions are still based on the historical 8/8 split. > > > > > > does anyone else find this a bit odd? > > > > No, we can't break the userspace abi, and so we need to internally > > handle the larger address space somehow. > > > > Do you see a better way to do this? > > not immediately. i hadn't really thought about it that much, i only > stumbled across this while reading LDD3 and following along in the > source code, when i realized that alloc_chrdev_region() limited itself > to an 8-bit major device number, even though the kernel-space major > number was a 12-bit value. Yes, if you want to use a bigger major, you need to use a different function. > i'm still unclear on how you can have a userspace ABI that clearly > interprets major and minor numbers differently from how they're > defined in the kernel. We still try to keep any dev_t that crosses into userspace to use the old style. I think it's only an issue with some filesystems. thanks, greg k-h -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
