tech-kern archive

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


On Sun, Dec 03, 2017 at 03:25:50PM -0500, Mouse wrote:
> > 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.

but how do you handle bluetooth interfaces then ?

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index