lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D405A9D.4070607@redhat.com>
Date:	Wed, 26 Jan 2011 15:32:13 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Mark Lord <kernel@...savvy.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils
 ?

Em 26-01-2011 13:05, Mark Lord escreveu:
> On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
>> On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
>>> On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
>>>> On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
>>>>> Em 25-01-2011 18:54, Dmitry Torokhov escreveu:
> ..
>>>>>> That has been done as well; we have 2 new ioctls and kept 2 old ioctls.
>>>>
>>>> That's the problem: you did NOT keep the two old ioctls().
>>>> Those got changed too.. so now we have four NEW ioctls(),
>>>> none of which backward compatible with userspace.
>>>>
>>>
>>> Please calm down. This, in fact, is not new vs old ioctl problem but
>>> rather particular driver (or rather set of drivers) implementation
>>> issue. Even if we drop the new ioctls and convert the RC code to use the
>>> old ones you'd be observing the same breakage as RC code responds with
>>> -EINVAL to not-yet-established mappings.
>>>
>>> I'll see what can be done for these drivers; I guess we could supply a
>>> fake KEY_RESERVED entry for not mapped scancodes if there are mapped
>>> scancodes "above" current one. That should result in the same behavior
>>> for RCs as before.
>>>
>>
>> I wonder if the patch below is all that is needed...
> 
> 
> Nope. Does not work here:
> 
> $ lsinput
> protocol version mismatch (expected 65536, got 65537)

You need to relax the version test at the tree. As I said before, this is
a development tool from the early RC days, bound to work with one specific
version of the API, and programmed by purpose to fail if there would by any
updates at the Input layer.

Cheers,
Mauro.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ