> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: wireless: recap of current issues (compatibility)
- From: Krzysztof Halasa <[email protected]>
- Re: wireless: recap of current issues (compatibility)
- References:
- wireless: recap of current issues (intro)
- From: "John W. Linville" <[email protected]>
- wireless: recap of current issues (compatibility)
- From: "John W. Linville" <[email protected]>
- wireless: recap of current issues (intro)
- Prev by Date: Re: wireless: recap of current issues (configuration)
- Next by Date: Re: wireless: recap of current issues (stack)
- Previous by thread: wireless: recap of current issues (compatibility)
- Next by thread: Re: wireless: recap of current issues (compatibility)
- Index(es):