Compatibility
=============
The netlink configuration mechanism needs compatibility code to
translate wireless extension ioctls into netlink transactions.
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (if it hasn't already).
We need an ethernet<->802.11 translational bridging interface for
compatibility, and to enable 802.1 bridging with ethernet. This could
be a configuration setting for a wlan interface. It might be limited
to wlan interfaces in station (or WDS) mode?
802.11 framing may break older protocols (e.g. DECnet). I don't
see this as a big problem, as I imagine such installations aren't
rolling-out lots of WiFi...if I'm wrong, will the translational
bridging code resolve this issue?
Should a default wlan device be created at WiPHY init? Should it
enable translational bridging? I'm inclined against this, but is it
worthwhile for compatibility? Could/should this be a configuration
option for the stack?
How about if WiPHY initialization triggered a netlink broadcast?
Then a daemon could monitor those broadcasts and create whatever wlan
devices (ethernet emulation, rfmon, none at all) that the daemon was
configured to create. How would this effect modprobe behaviour?
--
John W. Linville
[email protected]
> The netlink configuration mechanism needs compatibility code to
> translate wireless extension ioctls into netlink transactions.
I think we could restrict this to allow ioctl configuration only if
there's just a single active virtual dev [excluding some special cases
like changing the mode which would (see above) require deactivating one
and activating another virtual dev. or is that not possible without
screwing up naming etc? that might get tricky if we disallow mode
changing, but can probably be worked around easier than allowing mode
changing, especially since this is to be deprecated]
> Should a default wlan device be created at WiPHY init? Should it
> enable translational bridging? I'm inclined against this, but is it
> worthwhile for compatibility? Could/should this be a configuration
> option for the stack?
If you want the old userspace API to 'just work' you have to create one
default wlan device at WiPHY init.
> How about if WiPHY initialization triggered a netlink broadcast?
It definitely should, in any case.
johannes
Johannes Berg <[email protected]> writes:
> If you want the old userspace API to 'just work' you have to create one
> default wlan device at WiPHY init.
I'm not sure the old API is that important. This isn't something
programs (third party, kernel utils don't count) rely on. Most users
would switch to the new stack immediately anyway.
It could probably be a separate compatibility module, the core stack
probably don't have to know about it. The last to worry about I'd say.
--
Krzysztof Halasa