Re: wireless: recap of current issues (configuration)
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: 2006-01-14 00:06:05
Also in:
lkml
"John W. Linville" [off-list ref] writes:
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?
I think so. If needed one can delete and create.
Or something that can be changed when the net_device is down?
IMHO: unnecessary complicates things.
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.
If the control messages go through the main (WiPHY) driver it can decide and/or forward the request further, to the library. Not sure about netlink. OTOH I'm at all not sure netlink should be used for configuration. sysfs, ioctl seem a better options. Netlink is better for state monitoring etc. I don't know it very well though.
Do "global" config requests go to any associated wlan device?
Are they any global config settings? sysctl or sysfs maybe?
Or must they be directed to the WiPHY device? Does it matter?
If you mean "settings for a particular physical card" then WiPHY.
I think we should require "global" configuration to target the WiPHY device, while "local" configuration remains with the wlan device.
If "local" means "concerning the wlan device" then sure, yes.
(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?
I don't think so. The hardware driver should get the request first, the rest should look like a library. I've played with both approaches for years and I would avoid "802.11 using the hw driver" scenario if at all possible. -- Krzysztof Halasa