On Thu 2016-05-12 11:32:52, Johannes Berg wrote: > On Wed, 2016-05-04 at 09:29 +0200, Pavel Machek wrote: > > > > If userspace wants to control the manually, it can do just that -- > > control it manually. There should not be a need to "override the > > default policy". > > I'm still not buying this. > > In the original situation, without these patches, userspace has to have > a list of all LEDs that are supposed to indicate airplane mode. Well, that's situation for many LEDs. > With this patch only (without patch 2/3), userspace can look up the > default trigger, but then has to change it, causing the necessary > information to be lost immediately when you actually use it - that also > seems like a bad idea. We should not store "what kind of led this is" in a trigger. LED subsystem seems to use suffix of LED name to do that. So if we standartize, lets say "::rfkill" suffix for this, it should work and follow existing practice. > Now, if the LED subsystem had a really good way of specifying LED > intent, and it was widely used, and rfkill didn't already concern > itself with the rfkill status of all devices ... yeah maybe this > wouldn't be needed. As it stands, I still think this is the best way > forward. There is one -- suffix in the LED name. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
