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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200608302305.41075.dtor@insightbb.com>
Date:	Wed, 30 Aug 2006 23:05:40 -0400
From:	Dmitry Torokhov <dtor@...ightbb.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

On Monday 28 August 2006 16:15, Ivo van Doorn wrote:
> > 
> > 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.
> 
> Valid point, but when the radio is disabled a wireless interface should
> report a txpower of 0. I don't know if this is also the case for bluetooth or irda..
> 

Exactly...

> > 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.
> 
> Plain ifconfig actually, the rfkill is intentionally a simple kernel->userspace
> notification. There are already various ways a interface can be disabled and
> adding more would in my opinion not be a good thing.
> The reason for a hardware key event is to do something additionally besides
> simply turning down the radio of the (registered interfaces) because he might
> have additional interfaces to be shutdown, or there has to be done something
> with the interface before the radio is switched off.
> 

Well, this assumes that you have a network interface which may not be the
case. For example I could have a bluetooth keyboard or mouse instead of
network card. And you are proposing a generic solution...

> > 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.
> 
> This can indeed be done, would it not also make the input device redundant?
> Since userspace could also just poll a sysfs entry, and I on the netdev list the
> input device seemed to be prefered over sysfs polling.
>

Input device is good since then userspace connects to all of them and
waits for that specific event. The key (or switch) may even be generated
by another device (for example reassigning a key on my AT keyboard).
But I would probably keep RF control and input device separate instead of
mixing into one abstraction layer.

-- 
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/