From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Walmsley Subject: Re: [PATCH 0/7] usbhid: quirks cleanup, add dynamic quirks, ConfigFS interface Date: Thu, 12 Apr 2007 14:27:49 -0600 (MDT) Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-path: In-Reply-To: Sender: owner-linux-input@atrey.karlin.mff.cuni.cz List-Help: List-Owner: List-Post: List-Unsubscribe: To: Jiri Kosina Cc: linux-input@atrey.karlin.mff.cuni.cz, Joel Becker List-Id: linux-input@vger.kernel.org On Thu, 12 Apr 2007, Jiri Kosina wrote: > On Thu, 12 Apr 2007, Paul Walmsley wrote: > >> Now, another implementation approach would be to get rid of the quirk >> type names entirely, to use a path such as: >> >> /usbhid/quirks_runtime/: >> >> with the last component being a r/w configfs attribute containing the quirks >> value. Is that what you are proposing? I considered it when I did the >> initial implementation. The problem with it is that there seems to be no way >> for userspace to create new configfs files/attributes -- only configfs >> directories. > > Yes, this was my very original thought - I really somehow don't think that > having to duplicate every new quirk is a nice solution. Joel, is there any > specific reason why configfs doesn't allow this please? well, another approach would be to go to a layout like: /usbhid/blacklist/:/quirks in such a model, individual files would not have to be created or removed. Personally I think that having the quirk names broken out as individual files is more in line with the idea of 'one file per config attribute' that comes up in both the sysfs and configfs documentation. Besides, the worst thing that can happen if someone updates the HID_QUIRK #defines, but not hid_quirk_types[], is that the quirk won't be readable or modifiable from userspace, until someone fixes the mismatch. But ultimately, I don't think the choice of approach matters all that much, really. It's pretty marginal functionality. - Paul