On Wed, 2006-01-11 at 10:05 -0500, Mike Kershaw wrote: > Agreed, though there is a benefit to being able to specify the type of > the initial card. Many drivers offer it as a modprobe option, ie, to > initialize the card in rfmon to prevent it from sending any probe req's > before configuration. A bit of a fringe IDS aspect, but I don't know if > we ought to cut them out. Does anyone actually USE this functionality? > I don't, myself, but I know it exists.
Nah. Like Jiri said, as long as the dev isn't up it doesn't do anything. Not much point in this. That said, the driver is free to still provide that functionality. > I don't know if I concur -- having the "control" interface move around > is confusing. I'd rather have one unique ID for that wireless phy > (however this is presented) and then create dynamic devices from it via > whatever command. Atheros ties this to a master wifiX device that is > uses to spawn dynamic devices. It just seems that, logically, it makes > more sense to have something like: > wlanadddev phy0 dyn0 > wlanadddev phy0 dyn1 > wlanadddev phy1 dyn2 > wlandeldev dyn1 > wlandeldev dyn2 > wlanmakedev phy1 dyn1 > > rather than have the 'source' phy change over time. I thought I had addresses this already but maybe no one took notice. I think the 'master' device should not be represented as a net_dev at all, but be somewhat abstract. In that, you could delete the last real device attached to it and create a new one, in fact you might *have to* delete the last attached virtual device (which is a real net_dev) in order to make an incompatible one (well, I said it might suffice to bring the other ones down, which is ok too). > > - "Global" configuration requests (setting channel etc.) can be performed on > > any device and will affect all devices. > > Yup. I disagree. I rather envision a netlink protocol that says 'you cannot change the channel on just this single device' (unless the driver supports it), so you need a request saying 'change channel on all virtual devices'. Userspace helpers would tell the user that if necessary. > I'd like to know why. :) See above for my counter-argument about > confusing users. I'd be willing to agree that the control phy "master > device" doesn't need to be a netdev, but I think it ought to be a > constant, unique value. Tracking down what interface is still mapped to > what phy in a multicard situation seems like it would make a much bigger > hassle. I think that each of your cards in the multicard case is represented by an abstract 'master' device that is not a net_dev. Unless your driver wants to be smart enough to distribute the virtual devices over multiple physical devices it may control. johannes
signature.asc
Description: This is a digitally signed message part
