Thread (1 message) 1 message, 1 author, 2006-01-14

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help