Messages in this thread | | | Date | Thu, 13 Apr 2006 19:54:43 +0800 | From | Aubrey <> | Subject | Re: Is it a bug of ./include/linux/input.h? |
| |
Hi Vojtech,
I pull input git tree fromgit://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git and didn't see any change about this issue. You know, I can't just add a macro to the structure like this: ======================================================== #ifdef __KERNEL__ struct input_device_id { ...... kernel_ulong_t flags; ...... } #endif ======================================================== Because there is another file in the kernel using the header file "input.h", it's ./script/mod/file2alias.c.
Dmitry - It would be great if you can send the patch to me first. Thanks a lot.
Regards, -Aubrey
On 4/13/06, Aubrey <aubreylee@gmail.com> wrote: > Hi all, > > I encountered a problem when I compiled an input event test program "evtest". > The program included a kernel header file "input.h". Some parts of the > "input.h" file: > ========================================================== > #ifdef __KERNEL__ > #include <linux/time.h> > #include <linux/list.h> > #include <linux/device.h> > #include <linux/mod_devicetable.h> > #else > #include <sys/time.h> > #include <sys/ioctl.h> > #include <asm/types.h> > #endif > ............. > struct input_device_id { > > kernel_ulong_t flags; > > struct input_id id; > > kernel_ulong_t evbit[EV_MAX/BITS_PER_LONG+1]; > kernel_ulong_t keybit[KEY_MAX/BITS_PER_LONG+1]; > kernel_ulong_t relbit[REL_MAX/BITS_PER_LONG+1]; > kernel_ulong_t absbit[ABS_MAX/BITS_PER_LONG+1]; > kernel_ulong_t mscbit[MSC_MAX/BITS_PER_LONG+1]; > kernel_ulong_t ledbit[LED_MAX/BITS_PER_LONG+1]; > kernel_ulong_t sndbit[SND_MAX/BITS_PER_LONG+1]; > kernel_ulong_t ffbit[FF_MAX/BITS_PER_LONG+1]; > kernel_ulong_t swbit[SW_MAX/BITS_PER_LONG+1]; > > kernel_ulong_t driver_info; > }; > =========================================================== > The compilation error was caused by the type "kernel_ulong_t". When > define __KERNEL__, the type "kernel_ulong_t" will be defined in the > another header file "mod_deviceable.h". > So, if an user space application will include the "input.h", of course > the macro __KERNEL__ is not defined. Consequently, the application can > not be built. > > From my point of view, since the type "kernel_ulong_t" in the struct > input_device_id depends on the macro __KERNEL__, the struct > input_device_id should also depend on the macro. It shouldn't expose > to the user space. > > I'd like to make a patch about it. Is it acceptable? > > Regards, > -Aubrey > - 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/
| |