linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Michael Wu <flamingice@sourmilk.net>
Cc: Zhu Yi <yi.zhu@intel.com>,
	linux-wireless@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>,
	David Lamparter <lists@diac24.net>
Subject: Re: [Take 2] mac80211 IEEE802.11e/WMM code cleanup
Date: Sat, 16 Jun 2007 20:51:09 +0200	[thread overview]
Message-ID: <1182019869.9058.57.camel@johannes.berg> (raw)
In-Reply-To: <200706161129.13782.flamingice@sourmilk.net>

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

On Sat, 2007-06-16 at 11:29 -0700, Michael Wu wrote:

> I think that decision was made without much consideration to the 
> implementation details. 

I don't think the implementation details are much of a problem. It's
just a bit of message bouncing which is trivial. Except of course when
you consider wext, but hey, no need to consider that for this discussion
since you're proposing ditching wext completely. Not that I don't want
to ditch it, but people still use it and probably will. Heck, people
still use 'ifconfig'...

> I thought it was a good idea then, but passing 
> messages from userspace to the kernel and then to userspace again is really a 
> waste of time.

It's not happening a lot so it's not a waste of *much* time ;)

> NetworkManager already uses wpa_supplicant to avoid all the 
> nasty details of dealing with wireless configuration, so why not keep using 
> it for everything instead of hiding wpa_supplicant behind nl80211?

I hope that nm would start using nl80211 instead of talking to
wpa_supplicant and just start wpa_supplicant if necessary. Or maybe some
startup scripts start the userspace MLME (wpa_supplicant) for the
interfaces during boot/hotplug.

> This is 
> more simple and direct and allows the kernel to expose exactly what the 
> hardware/kernel can do. Userspace won't have to change much and nl80211 won't 
> have to support every possible thing a userspace MLME would want.

It's not that the kernel will have to support everything that a
userspace MLME would want, but rather that the kernel needs to support
everything the MLME would want, to support fullmac drivers.

Another counter: when you have a tool like 'iw' that David wrote, then
it'll need to look for the userspace MLME every time you invoke it and
start communicating with it instead of the kernel. That's likely a waste
of much more time than just bouncing the messages.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2007-06-16 18:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-11  8:59 [Take 2] mac80211 IEEE802.11e/WMM code cleanup Zhu Yi
2007-06-11 18:01 ` Johannes Berg
2007-06-12  7:37   ` Tomas Winkler
2007-06-12  8:18     ` Zhu Yi
2007-06-12 14:21       ` Tomas Winkler
2007-06-12  8:06   ` Zhu Yi
2007-06-12  9:35     ` Johannes Berg
2007-06-14  7:36     ` Johannes Berg
2007-06-14 16:35       ` Michael Wu
2007-06-16 12:27         ` Johannes Berg
2007-06-16 18:29           ` Michael Wu
2007-06-16 18:51             ` Johannes Berg [this message]
2007-06-16 22:16               ` Michael Wu
2007-06-17 12:03                 ` wireless userspace MLME and generic netlink vs. multicast (was: Re: [Take 2] mac80211 IEEE802.11e/WMM code cleanup) Johannes Berg
2007-06-18  2:08                   ` Zhu Yi
2007-06-18  8:46                     ` Johannes Berg
2007-06-17 15:29               ` [Take 2] mac80211 IEEE802.11e/WMM code cleanup Dan Williams
2007-06-18  8:41                 ` Johannes Berg
2007-06-18 11:09                   ` Johannes Berg

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=1182019869.9058.57.camel@johannes.berg \
    --to=johannes@sipsolutions.net \
    --cc=flamingice@sourmilk.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=lists@diac24.net \
    --cc=yi.zhu@intel.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;
as well as URLs for NNTP newsgroup(s).