From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Torokhov Subject: Re: [RFC][PATCH] input: Introduce device information ioctl Date: Thu, 9 Dec 2010 01:25:02 -0800 Message-ID: <20101209092502.GC8821@core.coreip.homeip.net> References: <1291706726-8835-1-git-send-email-rydberg@euromail.se> <20101207091653.GA22416@core.coreip.homeip.net> <4CFE919A.1040704@euromail.se> <20101208060200.GD4140@core.coreip.homeip.net> <4CFFD6D2.5060703@euromail.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-yw0-f46.google.com ([209.85.213.46]:34290 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754183Ab0LIJZL (ORCPT ); Thu, 9 Dec 2010 04:25:11 -0500 Content-Disposition: inline In-Reply-To: <4CFFD6D2.5060703@euromail.se> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Henrik Rydberg Cc: Jiri Kosina , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Ping Cheng , Chris Bagwell On Wed, Dec 08, 2010 at 08:04:50PM +0100, Henrik Rydberg wrote: > > One concern is that while 32 distinct device types should be enough > > > should we plan for larger capability array? Should we use variable > > length ioctl - like EVIOCGKEY(len) - even though Arnd does not like > > them? > > > Sounds good, but then again the struct approach feels quite extensible too... > Actually the more I think about it the less I like idea of extending the struct because while keeping ABI is pretty easy there are other issues. I'll CC you on EVIOCGKEYCODE patch so you can see my concerns. -- Dmitry