netdev - RE: [PATCH 6/6] d80211: add sysfs interface for QoS functions

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

Message-Id: <1166433533.10342.42.camel@debian.sh.intel.com>
Date:	Mon, 18 Dec 2006 17:18:53 +0800
From:	Zhu Yi <yi.zhu@...el.com>
To:	Simon Barber <simon@...icescape.com>
Cc:	netdev@...r.kernel.org
Subject: RE: [PATCH 6/6] d80211: add sysfs interface for QoS functions

On Thu, 2006-12-14 at 21:35 -0800, Simon Barber wrote:
> This is all part of the client MLME - it would be much better to add
> this functionality to wpa_supplicant, rather than adding it to the
> kernel. Nothing here needs to be in the kernel for any reason.

Theoretically, the whole network stack can be put into userspace. But we
gain performance and userspace tool independency from implementing it in
the kernel. Currently d80211 handles beacon, associate response and
other MLMEs, I see no reason why they need to be in the kernel according
to your point.

IMHO, for the MLME handling, if it involves policy or decision making
from the user, it should be done by the userspace, otherwise we
implement it in the kernel for better performance and userspace tool
independency.

Thanks,
-yi

> The client MLME functions that are in the kernel were put in there for
> test and debugging convenience only - the right client MLME to use is
> the one in wpa_supplicant. Especially with all the new and very
> complex
> MLME functions that are being added to 802.11 we do not want this huge
> amount of code in the kernel when it does not need to be there.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html