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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
