linux-kernel - Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

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: <20110126193259.GC29268@core.coreip.homeip.net>
Date:	Wed, 26 Jan 2011 11:32:59 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Mark Lord <kernel@...savvy.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 ?

On Wed, Jan 26, 2011 at 08:16:09PM +0100, Gerd Hoffmann wrote: >   Hi,
> 
> >>>The check should be against concrete version (0x10000 in this case).
> 
> Stepping back: what does the version mean?
>

Nothing, it is just a number.

> 0x10000 == 1.0 ?
> 0x10001 == 1.1 ?

No, not really.

> 
> Can I expect the interface stay backward compatible if only the
> minor revision changes, i.e. makes it sense to accept 1.x?

I am not planning on breaking backward compatibility.

> 
> Will the major revision ever change?  Does it make sense to check
> the version at all?

It depends. We do not have a clear way to see if new ioctls are
supported (and I do not consider "try new ioctl and see if data sticks"
being a good way) so that facilitated protocol version rev-up. So keymap
manipulating tools might be forced to check protocol version. For the
rest I think doing EVIOCGVERSION just to check that ioctl is supported
is an OK way to validate that we are dealing with an event device, but
that's it.

BTW, maybe we should move lsinput and input-kbd into linuxconsole
package, together with evtest, fftest, etc?

-- 
Dmitry
--
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/