Re: How does network manager read rfkill ?

[Dan Williams <dcbw redhat com>]

On Wed, 2009-04-29 at 16:33 +0300, Maxim Levitsky wrote:
> On Tue, 2009-04-28 at 12:11 -0400, Dan Williams wrote:
> > On Sat, 2009-04-25 at 00:45 +0300, Maxim Levitsky wrote:
> > > On Fri, 2009-04-24 at 12:49 -0400, Dan Williams wrote:
> > > > On Fri, 2009-04-24 at 18:16 +0300, Maxim Levitsky wrote:
> > > > > On Fri, 2009-04-24 at 11:06 -0400, Dan Williams wrote:
> > > > > > On Thu, 2009-04-23 at 22:35 +0300, Maxim Levitsky wrote:
> > > > > > > On Thu, 2009-04-23 at 07:15 -0400, Dan Williams wrote:
> > > > > > > > On Thu, 2009-04-23 at 02:16 -0400, eye zak wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I am writing low-level rfkill support in the ath5k driver in
> > > > > > > > > compat-wireless-2.6, and I am wondering how network manager knows
> > > > > > > > > about my rfkill device ?
> > > > > > > > > 
> > > > > > > > > Hal recognizes it no problem and broadcasts an event on state change,
> > > > > > > > > and tracks the current state. But netowork manager (jaunty-latest)
> > > > > > > > > does not notice it.
> > > > > > > > 
> > > > > > > > NM finds all devices in HAL with the capability 'killswitch', and polls
> > > > > > > > them every 6 seconds to find out if any of them return 0 for GetPower.
> > > > > > > > If any do, it assumes rfkill.  Are you sure NM is allowed to talk to HAL
> > > > > > > > on your distribution?  Some distros like Debian use different D-Bus
> > > > > > > > permissions styles, and if those are wrong in
> > > > > > > > the /etc/dbus-1/system.d/NetworkManager.conf, NM may not be able to talk
> > > > > > > > to HAL and get the killsiwtch state.
> > > > > > > > 
> > > > > > > > Dan
> > > > > > > 
> > > > > > > Or, it currently ignores platform kill switches, like acer-wmi
> > > > > > 
> > > > > > Do those rfkill switches expose themselves via HAL?  If so, then
> > > > > > NetworkManager is expected to work with them.  If not, then those need
> > > > > > to either (a) be ported to the kernel's rfkill subsystem in which case
> > > > > > they will be supported by HAL 0.5.12 automatically, or (b) get HAL
> > > > > > support otherwise.
> > > > > > 
> > > > > > Obviously (a) is preferred.
> > > > > > 
> > > > > 
> > > > > maxim maxim-laptop:~$ hald --version
> > > > > HAL package version: 0.5.12
> > > > > 
> > > > > I tried acer-wmi, and NM doesn't see it.
> > > > > It does expose normal rfkill interface
> > > > 
> > > > What distro?  Can you attach the lshal bits for all killswitches
> > > > contained in 'lshal' ?
> > > > 
> > > > Dan
> > > > 
> > > 
> > > Now I use ubuntu 9.04, but it was always present.
> > > 
> > > 
> > > 
> > > > udi = '/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'
> > > >   info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
> > > >   info.capabilities = {'killswitch'} (string list)
> > > >   info.category = 'killswitch'  (string)
> > > >   info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
> > > >   info.parent = '/org/freedesktop/Hal/devices/platform_acer_wmi'  (string)
> > > >   info.product = 'acer-wireless wlan Killswitch'  (string)
> > > >   info.subsystem = 'rfkill'  (string)
> > > >   info.udi = '/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'  (string)
> > > >   killswitch.access_method = 'rfkill'  (string)
> > > >   killswitch.name = 'acer-wireless'  (string)
> > > >   killswitch.state = 1  (0x1)  (int)
> > > >   killswitch.type = 'wlan'  (string)
> > > >   linux.hotplug_type = 2  (0x2)  (int)
> > > >   linux.subsystem = 'rfkill'  (string)
> > > >   linux.sysfs_path = '/sys/devices/platform/acer-wmi/rfkill/rfkill1'  (string)
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > > udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan'
> > > >   info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
> > > >   info.capabilities = {'killswitch'} (string list)
> > > >   info.category = 'killswitch'  (string)
> > > >   info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
> > > >   info.parent = '/org/freedesktop/Hal/devices/pci_8086_4222'  (string)
> > > >   info.product = '3945BG wlan Killswitch'  (string)
> > > >   info.subsystem = 'rfkill'  (string)
> > > >   info.udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan'  (string)
> > > >   info.vendor = 'Intel Corporation'  (string)
> > > >   killswitch.access_method = 'rfkill'  (string)
> > > >   killswitch.name = '3945BG'  (string)
> > > >   killswitch.state = 1  (0x1)  (int)
> > > >   killswitch.type = 'wlan'  (string)
> > > >   linux.hotplug_type = 2  (0x2)  (int)
> > > >   linux.subsystem = 'rfkill'  (string)
> > > >   linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/rfkill/rfkill0'  (string)
> > > > 
> > > > 
> > > 
> > > 
> > > Last time, a week ago or so, I installed ubuntu 9.04
> > > I disabled rfkill support in iwl3945, loaded acer-wmi, and yet NM didn't see the killswitch, even after a reboot
> > 
> > Do you ever get anything in syslog (wherever syslog directs the 'daemon'
> > facility) about "Found radio killswitch xxxx"?  If not, then we have to
> > do some more debugging, and if you can rebuild NM with a patch or two,
> > I'd be happy to help figure out where NM is going wrong.  Your lshal
> > looks fine.
> > 
> > Dan
> > 
> > 
> I have just redo the same, and acer-wmi works fine with NM. really don't
> know why it didn't. Sorry :-) for the noise.
> 
> 
> I have one question though, the default interval of polling is quite
> large, can you lower is to at least 3 seconds?

I picked 6 seconds as an arbitrary value because it seemed like a good
compromise between wakeups and responsiveness.  But honestly, 3 or 4
seconds would be fine too probably.

> I run it with 1 second interval, and don't see much influence on
> wakeups/cpu usage.
> 
> 
> Can't rfkill be interrupt driven instead, (I think NM supports such
> thing now, but could you explain more?)

2.6.27 and later support rfkill notifications to userspace via uevents,
but nothing before.  The rfkill code in NM does need a rewrite to handle
this better though.  I don't yet know if HAL proxies the state events
back out over D-Bus (last I checked it didn't) so either we make HAL do
that, or we make NM listen for the kernel events itself.

Dan