Bug#538389: rfkill into wireless-tools?
On Tue, Jul 28, 2009 at 09:29:56AM +0200, Johannes Berg wrote:
> On Tue, 2009-07-28 at 00:07 +0100, Darren Salt wrote:
> > I demand that Steve Langasek may or may not have written...
> > > On Sat, Jul 25, 2009 at 01:59:20PM +0100, Darren Salt wrote:
> > [snip; ITP for rfkill]
> > >> I'm choosing a git snapshot over 0.1 because it contains some
> > >> functionality which will be of use in eeepc-acpi-scripts.
> > > It's been proposed already to integrate this tool into the wireless-tools
> > > package; you may want to check with the maintainer of said package (and
> > > upstream) to sort out where this is best integrated.
> > I'm not convinced that it should, given the current description of
> > wireless-tools (for wext, basically); this would be broadening the scope of
> > that package somewhat. It may as well be merged into bluetooth, AFAICS...
> Or wimax tools, or 3G tools, or ... I agree with this, shipping it with
> wireless tools doesn't really seem appropriate. It's really used most
> for wifi and bluetooth, but the bluetooth stack now has its own rfkill
> soft instance like the wifi stack too.
FWIW, I'm still unclear why a special tool is needed to manage killswitches
now, since it used to be possible to set these directly via the interfaces
under /sys - the interfaces appear to still be there, but they no longer
accept changing the values, requiring access via a control device under
/dev instead. Surely this is a regression from the perspective of the
kernel design?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: