On Fri, 13 Jan 2006, John W. Linville wrote: > Configuration > ============= > > At init, physical devices should be represented by a "WiPHY" device, > not directly by a net_device. The list of physical devices should > be discoverable through netlink and/or sysfs. (A WiPHY device is an > abstraction representing the radio interface itself.)
I would suggest to start a level below, and have a WLAN device abstraction for a device connected to a bus. Conceptually this is an extension of the Linux device struct. This WLAN devices could have one or more WiPHY subdevices. A simple driver would have one WiPHY subdevice per RF transceiver. A complex driver could virtualize the RF transceiver and would allow to have dynamically created and removed WiPHY subdevices. In the standard case there will be only one WiPHY subdevice per WLAN device. > Virtual wlan devices should be associated to a WiPHY device many-to-one > (one-to-one for some devices). Virtual devices correspond to a net_device. May I suggest here to call this virtual devices interfaces. But I will continue to use your terminology. > 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? The net_device status should be independent from the WLAN MAC virtual device status. Reassociations for a moving WLAN device are a good example. I could even emagine to switch modes for an active net_device, as long the MAC address doesn't change, you should do be able to do everything at the MAC level. > 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. Yes virtual devices should be dynamically creatable and removable. I can't see, why a RFMON virtual device and its memory structures should be created, if in most cases it will not be used. Otherwise I would start with the assumption, that there are no dependencies between devices. Configuration of devices should be orthogonal. They one problem I can see is scanning over several frequencies. If two virtual devices are doing this at the same time, we have a conflict. Maybe each WiPHY would have only one active interface, which would allow the virtual device scanning over multiple frequencies and a number of passive interfaces, which don't allow to change frequencies. More than one WiPHy subdevice will be required, if two virtual devices want to do scanning. > 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?) 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? Maybe the active and passive interface concept could help here. I don't think, that the upper layer should filter conflicts, because this code must make assumptions about the capabilities of lower layer components. If these assumptions are wrong, the upper layer code must be changed. If there is a configuration, which can't be supported, the component configured should just say no. -- Ulrich Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
