On Wed, 2016-02-24 at 11:46 +0100, Pavel Machek wrote: > If you want different trigger, implement different trigger. If you > want to indicate all but wifi, implement all but wifi, and then > userspace can select it by writing trigger name.
This is still mostly a strawman, since userspace cannot have a database of LEDs that indicate airplane mode. I'm sure you'd also not like to see 2**7 triggers implemented in rfkill to cover all the possibilities. > If you want complete > userspace control, fine, but we have standard interface and it is not > ioctl. The "standard interface" is usable if you really just want to driver a single LED and you know which one. I think you're looking at this the wrong way, focusing too much on the LED aspect. Really what you have here is a concept of "airplane mode", and that concept is specific to the rfkill subsystem. This happens to affect mostly an LED trigger, today, but as a concept it's something that *should* be managed within the rfkill subsystem. > Besides, the series really should have been Cc-ed to LED > people, too. That's simply unreasonable, you're essentially saying that any user of any kernel infrastructure should be Cc'ed to the implementer of that infrastructure... 9/10 patches in this series aren't even LED specific, only the *previous* patch, the one that tied the "airplane mode" concept to an LED trigger in a very standard way had anything to do with LED triggers at all. johannes
