lkml.org 
[lkml]   [2011]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
    On Tue, Jan 25, 2011 at 12:54:53PM -0800, Dmitry Torokhov wrote:
    > On Wed, Jan 26, 2011 at 06:09:45AM +1000, Linus Torvalds wrote:
    > > On Wed, Jan 26, 2011 at 2:48 AM, Dmitry Torokhov
    > > <dmitry.torokhov@gmail.com> wrote:
    > > >
    > > > We should be able to handle the case where scancode is valid even though
    > > > it might be unmapped yet. This is regardless of what version of
    > > > EVIOCGKEYCODE we use, 1 or 2, and whether it is sparse keymap or not.
    > > >
    > > > Is it possible to validate the scancode by driver?
    > >
    > > More appropriately, why not just revert the thing? The version change
    >
    > Well, then we'll break Ubuntu again as they recompiled their input-utils
    > package (without fixing the check). And the rest of distros do not seem
    > to be using that package...
    >
    > > and the buggy EINVAL return both.
    >
    > I believe that -EINVAL thing only affects RC devices that Mauro switched
    > to the new rc-core; input core in itself should be ABI compatible. Thus
    > I'll leave the decision to him whether he wants to revert or fix
    > compatibility issue.
    >
    > >
    > > As Mark said, breaking user space simply isn't acceptable. And since
    > > breaking user space isn't acceptable, then incrementing the version is
    > > stupid too.
    >
    > It might not have been the best idea to increment, however I maintain
    > that if there exists version is can be changed. Otherwise there is no
    > point in having version at all.
    >
    > As I said, reverting the version bump will cause yet another wave of
    > breakages so I propose leaving version as is.
    >
    > >
    > > The way we add new ioctl's is not by incrementing some "ABI version"
    > > crap. It's by adding new ioctl's or system calls or whatever that
    > > simply used to return -ENOSYS or other error before, while preserving
    > > the old ABI. That way old binaries don't break (for _ANY_ reason), and
    > > new binaries can see "oh, this doesn't support the new thing".
    >
    > That has been done as well; we have 2 new ioctls and kept 2 old ioctls.
    >

    BTW, another issue is that evdev's ioctl returns -EINVAL for unknown
    ioctls so applications would have hard time figuring out whether error
    returned because of kernel being too old or because they are trying to
    retrieve/establish invalid mapping if they had to go only by the error
    code.

    As far as I can see EINVAL is a proper error for unknown ioctls:

    [dtor@hammer work]$ man 2 ioctl | grep EINVAL
    EINVAL Request or argp is not valid.
    [dtor@hammer work]$

    --
    Dmitry


    \
     
     \ /
      Last update: 2011-01-25 22:05    [W:0.039 / U:0.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site