HAL support for generic Linux RFKILL

[Marek Szuba]

Hello everyone,

Recently I have been messing around with connecting HAL to the
(relatively) recently-introduced RFKILL infrastructure of the Linux
kernel (see kernel_source_path/Documentation/rfkill.txt), as I was
rather surprised by the fact that even the most recent releases of hal
don't seem to support out of the box (by the way, is there anyone
working on this?). My meddling seems to have worked but is somewhat
crude, so I would like to discuss my results here.

The machine I use for working on this is an Eee PC 901 running the Linux
kernel 2.6.28, which offers two RFKILL-compatible kill-switches: one
for WLAN and one for Bluetooth. By default hald (version 0.5.11) didn't
seem to see any of them, plus a quick look at
hal-system-killswitch-[gs]et-power-linux has revealed to me the two
scripts only support some hardware-specific switches. So, what I have
done was:

 - in an information FDI file, checked the HAL device list for
   'info.subsystem == platform && platform.id == eeepc'; if such a
   device is present and we're under Linux, spawn two new UDIs (one
   for each kill-switch) with following properties set:
   info.capabilities (= killswitch), info.product (= descriptive
   names), info.category (=killswitch), killswitch.access_method (=
   rfkill), killswitch.type (= bluetooth/wlan), linux.sysfs_path
   (= /sys/class/rfkill/rfkillX, with values of X determined by eye);

 - in hal-system-killswitch-[gs]et-power-linux, added a check for
   '$HAL_PROP_KILLSWITCH_ACCESS_METHOD = rfkill' (without checking the
   killswitch type first, as the interface doesn't depend on it) which
   operates on $HAL_PROP_LINUX_SYSFS_PATH/state as needed. If you have
   difficulty imagining what happens there, these sections of the two
   scripts are not unlike the Thinkpad-related ones.

Like I said above, I'm not entirely happy with this solution even
though it works. Here is what bothers me:

1. The whole process gets triggered by the presence of the
platform-device 'eeepc', which quite obviously is a special rather than
general scenario. It would be much better to begin by looking for
RFKILL infrastructure having been set up instead, as it would both work
for all devices supporting it without having to check for any particular
controllers and save the HAL team from having to track what new
controllers have been made RFKILL-aware in each kernel release;

2. Sysfs paths are hardcoded, which is obviously bad. This is partially
related to the first issue, as starting with RFKILL devices (which are
identified in sysfs by names passed from their respective controllers)
would automatically give us appropriate sysfs paths;

3. RFKILL devices now sport uevent interface files, would it be
preferable (from the point of view of purity, unifying interfaces et
cetera) to use that in HAL scripts rather than manipulate individual
sysfs files?

4. What about the input-layer handler for RFKILL (the rfkill-input
module)? While using this is optional, there is no guarantee some user
doesn't enable it - and the docs state clearly that hands should be
kept off sysfs controls with rfkill-input active.


I'll be happy to hear what your comments on the subject are.

Regards,
-- 
MS