mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Aubrey <aubreylee@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Is it a bug of ./include/linux/input.h?
Date: Thu, 13 Apr 2006 12:53:06 +0200	[thread overview]
Message-ID: <20060413105306.GA5751@suse.cz> (raw)
In-Reply-To: <6d6a94c50604130242pecff7a1sbd994976e1f24ba@mail.gmail.com>

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

  reply	other threads:[~2006-04-13 10:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-13  9:42 Aubrey
2006-04-13 10:53 ` Vojtech Pavlik [this message]
2006-04-13 11:01   ` Aubrey
2006-04-13 11:54 ` Aubrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060413105306.GA5751@suse.cz \
    --to=vojtech@suse.cz \
    --cc=aubreylee@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®