Is it a bug of ./include/linux/input.h?

Is it a bug of ./include/linux/input.h?

[Aubrey]

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

Re: Is it a bug of ./include/linux/input.h?

[Vojtech Pavlik]

On Thu, Apr 13, 2006 at 05:42:17PM +0800, Aubrey 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?
 
Dmitry Torokhov has already fixed that in his tree, a fix should be
available reasonably soon.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: Is it a bug of ./include/linux/input.h?

[Aubrey]

Vojtech,

> Dmitry Torokhov has already fixed that in his tree, a fix should be
> available reasonably soon.
>

Thanks a lot, I'll pull Dmitry's tree to see how to fix it.

Regards,
-Aubrey

Re: Is it a bug of ./include/linux/input.h?

[Aubrey]

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
>