Linux wireless drivers development
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Tomas Winkler <tomasw@gmail.com>
Cc: Linux Wireless <linux-wireless@vger.kernel.org>,
	Dan Williams <dcbw@redhat.com>,
	"Abbas, Mohamed" <mohamed.abbas@intel.com>
Subject: Re: Rfkill on ifconfig up.
Date: Mon, 23 Jun 2008 10:04:01 -0300	[thread overview]
Message-ID: <20080623130401.GA3416@khazad-dum.debian.net> (raw)
In-Reply-To: <1ba2fa240806230302x11c0ed0dn6210c8fe745fdf6d@mail.gmail.com>

On Mon, 23 Jun 2008, Tomas Winkler wrote:
> On Mon, Jun 23, 2008 at 8:05 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Mon, 23 Jun 2008, Tomas Winkler wrote:
> >> Little RF KILL design question from user space perspective.
> >> What should be desired return value of ifconfig up when HW rfkill is
> >> on (radio is off).
> >
> > This isn't really about rfkill, its design doesn't call for any particular
> > behaviour.  IMHO we should go with the principle of least suprise, and also
> > more convenience for the user.
> 
> No, this is about ifconfig up
> 
> > In the end, it will depend on the capabilities of the hardware, I suppose.
> > Assuming the hardware CAN bring its interface up without going bonkers
> > because the transmitter is not transmitting anything, that's exactly what it
> > should do IMO.
> >
> > What it must never do is to unblock the transmiter because of a ifconfig up
> > :-)
> >
> >> rfkill on (radio off)
> >> ifconfig wlan0 up
> >> rfkill off (radio on)
> >>
> >> Will it be ok for these sequence to require additional ifconfig up to
> >> make driver to work, providing the first ifconfig up failed?
> >
> > It would be nice if it didn't fail the first ifconfig, and therefore needed
> > nothing special to work other than a rfkill unblock.
> 
> Everything is doable just 'would be nice'  is not good reason enough :)

Here's another one, then.  Most current WiFi cards do the "would be
nice" above, so we can just mandate it as the preferred way to go about
it.

Really, this IS about the hardware and driver capabilities.  rfkill is
not supposed to bring interfaces down, if that's another way to look at
your question.  But if it has to, it *is* entitled to do it.  In fact,
if it has to in order to shutdown a transmitter, it is entitled to
hotunplug and cut the power feed to the wireless device.

WiFi usually doesn't down interfaces.  At least on ThinkPads, Bluetooth
and WWAN do hotunplugging (which not only downs the interface, it
deletes the interface altogether), and I hear that is a common approach
for Bluetooth.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

      reply	other threads:[~2008-06-23 13:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-22 23:09 Rfkill on ifconfig up Tomas Winkler
2008-06-23  5:05 ` Henrique de Moraes Holschuh
2008-06-23 10:02   ` Tomas Winkler
2008-06-23 13:04     ` Henrique de Moraes Holschuh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080623130401.GA3416@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=dcbw@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mohamed.abbas@intel.com \
    --cc=tomasw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox