* EVIOCSFF macro inconsistency
@ 2014-09-08 18:14 Elias Vanderstuyft
2014-09-08 18:31 ` Dmitry Torokhov
0 siblings, 1 reply; 5+ messages in thread
From: Elias Vanderstuyft @ 2014-09-08 18:14 UTC (permalink / raw)
To: open list:HID CORE LAYER; +Cc: Dmitry Torokhov
Hi everyone,
After inspecting the <linux/input.h> header file, I found that there
is one single ioctl value macro that is inconsistent w.r.t. the other
macros that do an IOC_WRITE :
EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))
Why not define it as follows? :
EVIOCSFF _IOW('E', 0x80, struct ff_effect)
Apart from having a more readable definition, it also explicitly
reveals type info ("struct ff_effect").
Is it worth to create a patch to fix it?
Thanks,
Elias
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: EVIOCSFF macro inconsistency 2014-09-08 18:14 EVIOCSFF macro inconsistency Elias Vanderstuyft @ 2014-09-08 18:31 ` Dmitry Torokhov 2014-09-08 19:03 ` Elias Vanderstuyft 0 siblings, 1 reply; 5+ messages in thread From: Dmitry Torokhov @ 2014-09-08 18:31 UTC (permalink / raw) To: Elias Vanderstuyft; +Cc: open list:HID CORE LAYER Hi ELias, On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote: > Hi everyone, > > After inspecting the <linux/input.h> header file, I found that there > is one single ioctl value macro that is inconsistent w.r.t. the other > macros that do an IOC_WRITE : > EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) > Why not define it as follows? : > EVIOCSFF _IOW('E', 0x80, struct ff_effect) > Apart from having a more readable definition, it also explicitly > reveals type info ("struct ff_effect"). I think it is just historical. > Is it worth to create a patch to fix it? Sure, why not. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EVIOCSFF macro inconsistency 2014-09-08 18:31 ` Dmitry Torokhov @ 2014-09-08 19:03 ` Elias Vanderstuyft 2014-09-08 20:24 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Elias Vanderstuyft @ 2014-09-08 19:03 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: open list:HID CORE LAYER On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > Hi Elias, > > On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote: >> Hi everyone, >> >> After inspecting the <linux/input.h> header file, I found that there >> is one single ioctl value macro that is inconsistent w.r.t. the other >> macros that do an IOC_WRITE : >> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) >> Why not define it as follows? : >> EVIOCSFF _IOW('E', 0x80, struct ff_effect) >> Apart from having a more readable definition, it also explicitly >> reveals type info ("struct ff_effect"). > > I think it is just historical. > >> Is it worth to create a patch to fix it? > > Sure, why not. Cool, thanks! So probably the same applies to the IOC_READ counter parts? : EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len) EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len) EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len) EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len) EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len) EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len) EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len) EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len) EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len) EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len) to be converted to: EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len) EVIOCGKEY(len) _IOR('E', 0x18, len) EVIOCGLED(len) _IOR('E', 0x19, len) EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len) EVIOCGNAME(len) _IOR('E', 0x06, len) EVIOCGPHYS(len) _IOR('E', 0x07, len) EVIOCGPROP(len) _IOR('E', 0x09, len) EVIOCGSND(len) _IOR('E', 0x1a, len) EVIOCGSW(len) _IOR('E', 0x1b, len) EVIOCGUNIQ(len) _IOR('E', 0x08, len) Thanks, Elias ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EVIOCSFF macro inconsistency 2014-09-08 19:03 ` Elias Vanderstuyft @ 2014-09-08 20:24 ` Dmitry Torokhov 2014-09-08 20:42 ` Elias Vanderstuyft 0 siblings, 1 reply; 5+ messages in thread From: Dmitry Torokhov @ 2014-09-08 20:24 UTC (permalink / raw) To: Elias Vanderstuyft; +Cc: open list:HID CORE LAYER On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote: > On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > > Hi Elias, > > > > On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote: > >> Hi everyone, > >> > >> After inspecting the <linux/input.h> header file, I found that there > >> is one single ioctl value macro that is inconsistent w.r.t. the other > >> > >> macros that do an IOC_WRITE : > >> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) > >> > >> Why not define it as follows? : > >> EVIOCSFF _IOW('E', 0x80, struct ff_effect) > >> > >> Apart from having a more readable definition, it also explicitly > >> reveals type info ("struct ff_effect"). > > > > I think it is just historical. > > > >> Is it worth to create a patch to fix it? > > > > Sure, why not. > > Cool, thanks! > > So probably the same applies to the IOC_READ counter parts? : > EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len) > EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len) > EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len) > EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len) > EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len) > EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len) > EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len) > EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len) > EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len) > EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len) > to be converted to: > EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len) > EVIOCGKEY(len) _IOR('E', 0x18, len) > EVIOCGLED(len) _IOR('E', 0x19, len) > EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len) > EVIOCGNAME(len) _IOR('E', 0x06, len) > EVIOCGPHYS(len) _IOR('E', 0x07, len) > EVIOCGPROP(len) _IOR('E', 0x09, len) > EVIOCGSND(len) _IOR('E', 0x1a, len) > EVIOCGSW(len) _IOR('E', 0x1b, len) > EVIOCGUNIQ(len) _IOR('E', 0x08, len) No, because 'len' is not a type. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: EVIOCSFF macro inconsistency 2014-09-08 20:24 ` Dmitry Torokhov @ 2014-09-08 20:42 ` Elias Vanderstuyft 0 siblings, 0 replies; 5+ messages in thread From: Elias Vanderstuyft @ 2014-09-08 20:42 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: open list:HID CORE LAYER On Mon, Sep 8, 2014 at 10:24 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote: >> On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov >> >> <dmitry.torokhov@gmail.com> wrote: >> > Hi Elias, >> > >> > On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote: >> >> Hi everyone, >> >> >> >> After inspecting the <linux/input.h> header file, I found that there >> >> is one single ioctl value macro that is inconsistent w.r.t. the other >> >> >> >> macros that do an IOC_WRITE : >> >> EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) >> >> >> >> Why not define it as follows? : >> >> EVIOCSFF _IOW('E', 0x80, struct ff_effect) >> >> >> >> Apart from having a more readable definition, it also explicitly >> >> reveals type info ("struct ff_effect"). >> > >> > I think it is just historical. >> > >> >> Is it worth to create a patch to fix it? >> > >> > Sure, why not. >> >> Cool, thanks! >> >> So probably the same applies to the IOC_READ counter parts? : >> EVIOCGBIT(ev,len) _IOC(_IOC_READ, 'E', 0x20 + (ev), len) >> EVIOCGKEY(len) _IOC(_IOC_READ, 'E', 0x18, len) >> EVIOCGLED(len) _IOC(_IOC_READ, 'E', 0x19, len) >> EVIOCGMTSLOTS(len) _IOC(_IOC_READ, 'E', 0x0a, len) >> EVIOCGNAME(len) _IOC(_IOC_READ, 'E', 0x06, len) >> EVIOCGPHYS(len) _IOC(_IOC_READ, 'E', 0x07, len) >> EVIOCGPROP(len) _IOC(_IOC_READ, 'E', 0x09, len) >> EVIOCGSND(len) _IOC(_IOC_READ, 'E', 0x1a, len) >> EVIOCGSW(len) _IOC(_IOC_READ, 'E', 0x1b, len) >> EVIOCGUNIQ(len) _IOC(_IOC_READ, 'E', 0x08, len) >> to be converted to: >> EVIOCGBIT(ev,len) _IOR('E', 0x20 + (ev), len) >> EVIOCGKEY(len) _IOR('E', 0x18, len) >> EVIOCGLED(len) _IOR('E', 0x19, len) >> EVIOCGMTSLOTS(len) _IOR('E', 0x0a, len) >> EVIOCGNAME(len) _IOR('E', 0x06, len) >> EVIOCGPHYS(len) _IOR('E', 0x07, len) >> EVIOCGPROP(len) _IOR('E', 0x09, len) >> EVIOCGSND(len) _IOR('E', 0x1a, len) >> EVIOCGSW(len) _IOR('E', 0x1b, len) >> EVIOCGUNIQ(len) _IOR('E', 0x08, len) > > No, because 'len' is not a type. Indeed, just found out by myself, thank you for the confirmation. Elias ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-09-08 20:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-08 18:14 EVIOCSFF macro inconsistency Elias Vanderstuyft 2014-09-08 18:31 ` Dmitry Torokhov 2014-09-08 19:03 ` Elias Vanderstuyft 2014-09-08 20:24 ` Dmitry Torokhov 2014-09-08 20:42 ` Elias Vanderstuyft
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.