tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


> Now I'm wondering what we should do with this event, and where it
> should be handled.  I can think of two solutions:

> - handle it in kenrel: have all wifi and bluetooth interfaces listen
>    to the event and act on it.  One problem is synchronisation: the
>    event doesn't carry information on radio state (on or off), so in
>    machines with multiple radio, we could end up with some on and
>    some off, and the event toggles everything so we can never have
>    all radios on or off.  So we'd need a global radio state.

Not necessarily.  See below.

> - handle it in userland.  This can give more flexibility on what and
>    how to turn on/off.  It may also be more difficult to control all
>    the radio at once (how do we get a list of all radio interfaces in
>    userland?)

Speaking as a putative user/sysadmin, I would actually want to be able
to control what interfaces get affected by the switch.  For example, I
might want a single press to turn wifi on or off without affecting
bluetooth, whereas (say) two presses less than a second apart turns all
radios off, or returns them to their previous state.

Of course, this is inconsistent with neither of the above, though the
details would vary.

As for a list of interfaces?  Do what ifconfig -l does and then filter
based on type, would be my raction.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index