linux-kernel - Re: [PATCH] RFKILL - Add support for input key to control wireless radio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <d120d5000608280847n221b6d89y93c8cba747d84890@mail.gmail.com>
Date:	Mon, 28 Aug 2006 11:47:12 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Ivo van Doorn" <ivdoorn@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	"John W. Linville" <linville@...driver.com>,
	"Jiri Benc" <jbenc@...e.cz>
Subject: Re: [PATCH] RFKILL - Add support for input key to control wireless radio

Hi ivo,

On 8/27/06, Ivo van Doorn <ivdoorn@...il.com> wrote:
> Hi,
>
> This driver has previously be send to the netdev list for inclusion
> in the wireless-dev tree. But before it can be applied there this
> patch needs  an stamp of approoval from the Input layer maintainer.
>
> Modern (and even older) laptops often have a key to enable or disable
> the radio of a wireless device (WIFI, IRDA, Bluetooth, etc).
> It is however not always the case that the button controls the hardware
> directly. The rfkill driver will provide a uniform interface for hardware
> drivers to hook the button on and to provide a single method to report
> the state of the button to userspace.
>
> For each button a input device is created, after which rfkill will start polling
> for the button state. The polling will only occur if the button requires polling,
> but rfkill also provide a handler for the hardware driver to report the button
> status to rfkill. Once the status of any button has changed (detected either
> by polling or by notification from hardware driver) it will go through all
> registered hardware and will enable/disable the radio of the device if the
> input device has not been opened by the user. If the input device has been
> openend by the user the radio will not be touched and the event will be send
> to userspace to allow userspace to deal with the situation.
>

I am not sure if this is a correct approach, kernel should not assume
that the reason why input device was opened is to control the state of
the transmitter. For example one could be happy with hardware toggling
the state but still want to have for example a GKrellm showing state
of the transmitter.

Also please explain how userspace would control the state of
transmitter once KEY_RFKILL is received - there seems to be only
kernel->userspace link, but not userspace->kernel.

I would rather see you implemented a transmitter control framework
that would export couple of sysfs attributes. One attribute would
enable/disable controlling transmitter state automatically by the
driver and another  would allow controlling transmitter from
userspace. Then input device would always deliver events to userspace
(btw, it probably shoudl be switch, not a key event) and it would be
up to userspace program to explicitely take control over.

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/