lkml.org 
[lkml]   [2016]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)
    On Wed 2016-02-24 14:31:33, Johannes Berg wrote:
    > 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.

    Well, conventional way to solve this is to simply name the led
    "acer::airplane"... that way it is persistent. We already do that for
    display/keyboard backlights.

    > 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...

    Take a look at the blinking triggers.

    > > > 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.

    So... the LED changes meaning during boot? That's surely not a nice
    solution.

    So... you rather store bit in a kernel with unclear semantics,
    explaining "oh I need to leave the flexibility to userland"? Sorry,
    that's just ugly.

    > > 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.

    New LED trigger and new ioctl for LED control... not matching how LEDs
    are normally controlled.

    Best regards,
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

    \
     
     \ /
      Last update: 2016-02-25 10:41    [W:2.962 / U:0.600 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site