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/<vendor_id>:<product_id>
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/<vendor_id>:<product_id>/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
