netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: wireless: recap of current issues (configuration)
Date: Fri, 13 Jan 2006 17:19:36 -0500	[thread overview]
Message-ID: <20060113221935.GJ16166@tuxdriver.com> (raw)
In-Reply-To: <20060113213011.GE16166@tuxdriver.com>

Configuration
=============

Configuration seems to be coalescing around netlink.  Among other
things, this technology provides for muliticast requests and
asynchronous event notification.

The kernel should provide generic handlers for netlink
configuraion messages, and there should be a per-device 80211_ops
(wireless_ops? akin to ethtool_ops) structure for drivers to
populate appropriately.

At init, physical devices should be represented by a "WiPHY" device,
not directly by a net_device.  The list of physical devices should
be discoverable through netlink and/or sysfs.  (A WiPHY device is an
abstraction representing the radio interface itself.)

Virtual wlan devices should be associated to a WiPHY device many-to-one
(one-to-one for some devices).  Virtual devices correspond to a net_device.

Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
raw?, other modes?) which defines its "on the air" behaviour.  Should
this mode be fixed when the wlan device is created?  Or something
that can be changed when the net_device is down?

It may be necessary to remove, suspend, and/or disable wlan devices
in order to add, resume, and/or enable other types of wlan devices
on the same WiPHY device (especialy true for rfmon).  A mechanism is
needed for drivers to be able to influence or disallow combinations
of wlan devices in accordance with capabilities of the hardware.

Do "global" config requests go to any associated wlan device?
Or must they be directed to the WiPHY device?  Does it matter?
I think we should require "global" configuration to target the WiPHY
device, while "local" configuration remains with the wlan device.
(I'm not sure how important this point is?)  Either way, the WiPHY
device will need some way to be able to reject configuration requests
that are incompatible among its associated wlan devices.  Since the
wlan interface implementations should not be device specific, perhaps
the 802.11 stack can be smart enough to filter-out most conflicting
config requests before they get to the WiPHY device?
-- 
John W. Linville
linville@tuxdriver.com

  parent reply	other threads:[~2006-01-13 22:19 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060113195723.GB16166@tuxdriver.com>
2006-01-13 21:26 ` wireless: recap of current issues (intro) John W. Linville
     [not found]   ` <20060113213011.GE16166@tuxdriver.com>
2006-01-13 22:19     ` John W. Linville [this message]
2006-01-13 22:32       ` wireless: recap of current issues (configuration) Johannes Berg
2006-01-14  1:17         ` Stuffed Crust
2006-01-14  9:28           ` Johannes Berg
2006-01-14 13:47             ` Krzysztof Halasa
2006-01-14 22:07           ` Jeff Garzik
2006-01-15 15:20             ` Stuffed Crust
2006-01-15 19:05               ` Samuel Ortiz
2006-01-16 17:09                 ` Stuffed Crust
2006-01-16 18:51                   ` Samuel Ortiz
2006-01-16 19:06                     ` John W. Linville
2006-01-16 20:16                       ` Samuel Ortiz
2006-01-16 21:06                         ` Stuffed Crust
2006-01-16 22:24                       ` Alan Cox
2006-01-16 23:02                         ` John W. Linville
2006-01-17 18:41                         ` Stuffed Crust
2006-01-17 18:54                           ` Kyle Moffett
2006-01-15 19:53               ` Sam Leffler
2006-01-16 17:28                 ` Stuffed Crust
2006-01-16 17:54                   ` Sam Leffler
2006-01-16 19:40                     ` Stuffed Crust
2006-01-16 20:14                       ` Sam Leffler
2006-01-16 20:58                         ` Stuffed Crust
2006-01-16 18:39                   ` Dan Williams
2006-01-16 19:07                   ` Samuel Ortiz
2006-01-16 19:50                     ` Stuffed Crust
2006-01-16 20:10                       ` Samuel Ortiz
2006-01-15 12:40         ` Stefan Rompf
2006-01-15 15:51           ` Johannes Berg
2006-01-15 17:53             ` Stefan Rompf
2006-01-15 20:08               ` Sam Leffler
2006-01-15 20:11                 ` Johannes Berg
2006-01-17 22:20                   ` Stefan Rompf
2006-01-15 19:39           ` Sam Leffler
2006-01-16  0:06             ` Mike Kershaw
2006-01-16 14:23         ` Jiri Benc
2006-01-16 14:55           ` Johannes Berg
2006-01-16 17:33             ` Stuffed Crust
2006-01-16 18:00               ` Sam Leffler
2006-01-16 20:16                 ` Stuffed Crust
2006-01-14  0:05       ` Krzysztof Halasa
2006-01-14 23:41       ` Dan Williams
2006-01-15 16:18         ` Stuffed Crust
2006-01-15  9:35       ` feyd
     [not found]   ` <20060113213126.GF16166@tuxdriver.com>
2006-01-13 22:20     ` wireless: recap of current issues (compatibility) John W. Linville
2006-01-13 22:33       ` Johannes Berg
2006-01-14 13:44         ` Krzysztof Halasa
     [not found]   ` <20060113213237.GH16166@tuxdriver.com>
2006-01-13 22:24     ` wireless: recap of current issues (other issues) John W. Linville
2006-01-13 22:35       ` Johannes Berg
2006-01-13 23:02         ` Johannes Berg
2006-01-14 22:09       ` Jeff Garzik
2006-01-15  0:54         ` John W. Linville
2006-01-15  1:51         ` David S. Miller
2006-01-15 11:23           ` Arnaldo Carvalho de Melo
2006-01-15 15:39         ` Stuffed Crust
2006-01-17 23:36           ` wireless: recap of current issues (other issues / fake ethernet) Stefan Rompf
2006-01-18 16:32             ` Stuffed Crust
     [not found]   ` <20060113213311.GI16166@tuxdriver.com>
2006-01-13 22:25     ` wireless: recap of current issues (actions) John W. Linville
2006-01-13 22:36       ` Johannes Berg
2006-01-14 22:11       ` Jeff Garzik
2006-01-15  0:56         ` John W. Linville
2006-01-16 14:44           ` Johannes Berg
     [not found]   ` <20060113213200.GG16166@tuxdriver.com>
2006-01-13 22:22     ` wireless: recap of current issues (stack) John W. Linville
2006-01-13 22:34       ` Johannes Berg
2006-01-13 23:03     ` Chase Venters
2006-01-14 10:46       ` Simon Kelley
2006-01-14 23:29         ` Dan Williams
2006-01-14 13:51       ` Michael Buesch
2006-01-17 17:38         ` Jean Tourrilhes
2006-01-14 14:13     ` Ulrich Kunitz
2006-01-15  4:42       ` Pete Zaitcev
2006-01-15 10:04         ` Ulrich Kunitz
     [not found] ` <43C80F9A.8020203@candelatech.com>
2006-01-13 22:49   ` wireless: recap of current issues Ben Greear

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=20060113221935.GJ16166@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).