[PATCH] mknod fix for major/minor number greater than 255

Basheer, Mansoor Ahamed mansoor.ahamed at ti.com
Wed Mar 12 14:05:10 UTC 2008




 
Basheer, Mansoor Ahamed wrote:
> > Khem Raj wrote:
> >
> >> On Mar 11, 2008, at 11:56 PM, Basheer, Mansoor Ahamed wrote:
> >>
> >>
> >>> Robert Wrote [mailto:rpjday at crashcourse.ca]
> >>>
> >>>> On Tue, 11 Mar 2008, Khem Raj wrote:
> >>>>
> >>>>
> >>>>> On Mar 11, 2008, at 11:03 PM, Basheer, Mansoor Ahamed wrote:
> >>>>>
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Current mknod implementation fails for major/minor number
greater
> >>>>>>
> >>> than
> >>>
> >>>> 255.
> >>>>
> >>>>> is linux kernel supporting major/minor numbers greater than 255
?
> >>>>>
> >>>> the *kernel* supports major/minor numbers of bit length (12,20).
> >>>> it's
> >>>> only userspace that restricts their values to (8,8).
> >>>>
> >>>>
> >>> Yes Robert you are right. For example USB endpoint devices use
major
> >>> 442
> >>> (drivers/usb/core/endpoint.c).
> >>>
> >>> Also, __kernel_dev_t for ARM should be "unsigned int" and not
> >>> "unsigned
> >>> short".
> >>>
> >>> Signed-off-by: Mansoor Ahamed <mansoor.ahamed at ti.com>
> >>>
> >>> --- libc/sysdeps/linux/common/mknod.c 2008-03-11
17:43:54.000000000
> >>> +0530
> >>> +++ libc/sysdeps/linux/common/mknod.c 2008-03-11
17:45:21.000000000
> >>> +++ +0530
> >>> @@ -20,9 +20,8 @@ static inline _syscall3(int, __syscall_m  int
> >>> mknod(const char *path, mode_t mode, dev_t dev)  {
> >>>        /* We must convert the dev_t value to a __kernel_dev_t */
> >>> -       __kernel_dev_t k_dev;
> >>> +       __kernel_dev_t k_dev = (__kernel_dev_t)dev;
> >>>
> >>> -       k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff);
> >>>        return __syscall_mknod(path, mode, k_dev);  }
> >>> libc_hidden_def(mknod)
> >>>
> >> OK. the change looks ok. A testcase would be good to have.
> >>
> >>
> >>>
> >>>
> >>> --- libc/sysdeps/linux/arm/bits/kernel_types.h
> >>> +++ libc/sysdeps/linux/arm/bits/kernel_types.h
> >>> @@ -7,7 +7,7 @@
> >>> #ifndef __ARCH_ARM_POSIX_TYPES_H
> >>> #define __ARCH_ARM_POSIX_TYPES_H
> >>>
> >>> -typedef unsigned short         __kernel_dev_t;
> >>> +typedef unsigned int           __kernel_dev_t;
> >>> typedef unsigned long          __kernel_ino_t;
> >>> typedef unsigned short         __kernel_mode_t;
> >>> typedef unsigned short         __kernel_nlink_t;
> >>> @@ -31,7 +31,7 @@
> >>> typedef unsigned short         __kernel_old_uid_t;
> >>> typedef unsigned short         __kernel_old_gid_t;
> >>> typedef long long              __kernel_loff_t;
> >>> -typedef __kernel_dev_t         __kernel_old_dev_t;
> >>> +typedef unsigned short         __kernel_old_dev_t;
> >>>
> >>>
> >> This also looks ok.
> >>
> >>
> >>> typedef struct {
> >>> #ifdef __USE_ALL
> >>>
> >>>
> >
> > How do I provide the test application? I should register for svn
> > developer access or attach the test application in an email?
> >
> > -Mansoor
> >

I have attached test application with this mail.

-Mansoor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tst1-mknod.c
Type: application/octet-stream
Size: 1712 bytes
Desc: tst1-mknod.c
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20080312/48caa6ac/attachment-0002.obj 


More information about the uClibc mailing list