Re: rfkill-input madness

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]

On Mon, 2009-03-30 at 10:23 -0300, Henrique de Moraes Holschuh wrote:
> On Sat, 28 Mar 2009, Johannes Berg wrote:
> > Ok so you want to add "global" states mostly -- that's fine, but not all
> > that useful since userspace cannot really claim globally. I also don't
> > see a point -- if userspace wanted to do global stuff it might just as
> > well do nothing.
> 
> The point of doing global stuff is to do rfkill-input in userspace, the way
> userspace might want to do it.
> 
> Without the global state being exposed, userspace really can't do anything
> properly, and rfkill-input is needed for any semblance of good rfkill input
> event handling.

Right -- but I've been wondering about those global states completely. I
still need to look at input.c in more detail though. It seems that it
can trivially get out of sync, if for example a global event turns _all_
radios off, but then a wlan event turns wlan back on, and then what's
the state of the "all" switch?

> I can't say I strongly want it, since I am happy enough with rfkill-input,
> though.  But the API to userspace _is_ incomplete if the global states and
> global functionality are not exposed.

I've kinda removed the entire userspace API part from rfkill, mostly out
of laziness (so I guess I'll add it back) but also because I don't quite
see the point. Has anyone come up with a usecase for it?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]