Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1341933

Re: custom ioctl-based interface to control LED in networking (was Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode)

Show all headers | View raw

On Wed 2016-02-24 12:01:37, Johannes Berg wrote:
> 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.

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

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

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

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

> > 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.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Pavel Machek <pavel@ucw.cz> - 2016-02-23 21:50 +0100
  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-23 22:00 +0100
    Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Pavel Machek <pavel@ucw.cz> - 2016-02-23 22:50 +0100
      Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 10:10 +0100
        custom ioctl-based interface to control LED in networking (was Re:  [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-24 11:50 +0100
          Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 12:10 +0100
            Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-24 13:20 +0100
              Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Johannes Berg <johannes@sipsolutions.net> - 2016-02-24 14:40 +0100
                Re: custom ioctl-based interface to control LED in networking (was  Re: [PATCHv2 09/10] rfkill: Userspace control for airplane mode) Pavel Machek <pavel@ucw.cz> - 2016-02-25 10:10 +0100

csiph-web