On Thu, Mar 22, 2007 at 06:20:04PM -0400, Robert P. J. Day wrote: > On Thu, 22 Mar 2007, Mike Frysinger wrote: > > > On 3/22/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > > given that the current definition of a major device number is a > > > 12-bit value (include/linux/kdev_t.h), is there any reason that > > > dynamic allocation of major numbers via alloc_chrdev_region() limits > > > itself based on the value of > > > > > > include/linux/fs.h:#define CHRDEV_MAJOR_HASH_SIZE 255 > > > > > > sure, i realize there's no real danger of running out of major > > > numbers, but i'm just curious. i'm wondering what other places in the > > > source tree might have a hard-coded value of 255 for that. > > > > probably historical ? dev_t wasnt always as large as it is now ... > > -mike > > oh, i realize *that*. i was just wondering why the definition of > CHRDEV_MAJOR_HASH_SIZE wasn't keeping up with the definition of > kdev_t. > > actually, more curiously, 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? 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
