On Wed, 2016-02-24 at 13:14 +0100, Pavel Machek wrote:

Why would it need to? It could look at default triggers for the led
if it really wanted to.

And then it needs to change them; if anything goes wrong error recovery
is practically impossible since the trigger information is lost
forever.

quoted

I'm sure you'd also not like to see 2**7 triggers implemented in
rfkill
to cover all the possibilities.

Are all the possibilities useful? I assumed about 2 are. If you need
2**7 of them, LED triggers can have parameters.

It's not my position to decide which combinations some system
integrator or userspace developer might find useful.

Even when we add parameters to a trigger (I don't see a generic way to
do that, but please do enlighten me), you're now ignoring the issue of
the userspace controlled GSM modem...

quoted

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.

How is that concept used outside the LEDs? What semantics does
"airplane mode" have? You tried to explain "airplane mode" is not
well defined up in this thread...

I'd say it's well-defined for any given set of system software, so if
e.g. NetworkManager decides to define it one way, and connman another
way, there's a definition but the kernel need not interfere with it.

quoted

quoted

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,

I'm not saying that. I'm saying that LED maintainers should be Cced,
to keep the interfaces consistent.

I pretty much have to read it that way, since the LED API is in no way
impacted by these changes. Here's a new trigger, with some magic inner
working. No impact on the LED API.

johannes