EVIOCSFF macro inconsistency

5 messages, 2 authors, 2014-09-08 · open the first message on its own page

EVIOCSFF macro inconsistency

From: Elias Vanderstuyft <hidden>
Date: 2014-09-08 18:14:14 

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

Re: EVIOCSFF macro inconsistency

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2014-09-08 18:32:02 

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

Re: EVIOCSFF macro inconsistency

From: Elias Vanderstuyft <hidden>
Date: 2014-09-08 19:03:12 

On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov
[off-list ref] wrote:
Hi Elias,

On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
quoted
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.
quoted
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

Re: EVIOCSFF macro inconsistency

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2014-09-08 20:24:26 

On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote:
On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov

[off-list ref] wrote:
quoted
Hi Elias,

On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
quoted
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.
quoted
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

Re: EVIOCSFF macro inconsistency

From: Elias Vanderstuyft <hidden>
Date: 2014-09-08 20:42:39 

On Mon, Sep 8, 2014 at 10:24 PM, Dmitry Torokhov
[off-list ref] wrote:
On Monday, September 08, 2014 09:03:11 PM Elias Vanderstuyft wrote:
quoted
On Mon, Sep 8, 2014 at 8:31 PM, Dmitry Torokhov

[off-list ref] wrote:
quoted
Hi Elias,

On Mon, Sep 08, 2014 at 08:14:13PM +0200, Elias Vanderstuyft wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help