Re: wireless: recap of current issues (configuration)

[Johannes Berg <johannes@sipsolutions.net>]

[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]

> 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?

IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part of my thinking is that
different virtual types have different structures associated, so
changing it needs re-creating structures anyway. And different virtual
device types might even be provided by different kernel modules so you
don't carry around AP mode if you don't need it.

> 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?)

Right [global config targets wiphy]. I do think this is an important UI
issue that userspace will have to tackle, but I think the correct way
for the kernel is to surface this issue instead of creating workarounds.

> 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'm not sure this is worth it. While putting this into the WiPHY device
creates more logic there, putting knowledge like 'how many different
channels can this WiPHY device support' etc. into some representation
that can be used by the stack to decide is much more trouble than it is
worth.

johannes

Attachment: signature.asc
Description: This is a digitally signed message part