On Wed, 2009-05-27 at 11:00 -0300, Henrique de Moraes Holschuh wrote: > Well, thinkpad-acpi has users of that functionality, and not just that, it > is in the middle of a two year effort to deprecate the thinkpad-acpi > specific driver attributes and switch to just rfkill. This effort will be > destroyed if a kernel releases without support to writes to the "state" > attribute. > > I need that userspace interface (writes to the state attribute) in place and > working. It _is_ a big regression for thinkpad-acpi to have it return > -EOPNOTSUPP. You're free to implement a sane API -- I don't think the current API is feasible because we need to be able to set the soft state regardless of the hard state, query each state separately, and ideally poll the states. Also, the old user_claim is crap when it comes to userspace apps 'forgetting' to reset it when they're finished. I was suggesting earlier today to John that it might make sense to create a character device for each rfkill instance so that you can * read soft/hard state from it * while the device is open for write, that's the equivalent of user_claim * you can poll() the fd for the device instead of having to listen to the stupid uevents Also, I want to have any actual proper use cases like switching between classes covered better. > Also, regardless of the "claim" attribute (and the related > user_claim_unsupported nonsense), the old core would allow the user to > change the soft state using sysfs, so I really don't understand what you > mean when you say "almost all drivers disabled that functionality", you > can't disable writes to the "state" attribute in the old core from what I > can see. Please correct me if I am wrong on this. Without user_claim userspace can have no expectation of actually having control over the state attribute. If your userspace tools do not always user_claim before I believe they are broken. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
