On Tue, 2007-12-11 at 15:52 +0100, Johannes Berg wrote: > > > 2) that can be changed in userspace, but we couldn't figure out a scenario > > > where it would make any sense. Johannes, any comments? Wouldn't it make > > > sense to just forbid to change this in userspace? > > > > I don't agree. For example, what if you have some broken 802.11b only > > hardware that you desperately need to get going, but it freaks out on > > 802.11g encoded frames. Now if your AP is hostapd on a Linux machine, > > you'll want to change the mode. Hence, also the number of available > > rates change. > > > > Moreover, I think we can do better than just disallowing changes to the > > rate set, don't you think? > > All of this is going to change anyway, but disallowing mode/rateset > changes while associated is definitely the right thing to do. Just to sum up the issue for Johannes: Stefano's patch adds per-rate information to the PID algorithm state. This is fine, however we need to make sure the rate control algorithm gets reinitialized when the number of rates changes (i.e. due to a mode change, what about about regulatory domain changes?), as otherwise we might be indexing array entries we don't have allocated. Now this spawned the more general discussion about when the stack should allow changing modes etc. So let's go back to the original issue: Johannes, can we assume rate control always gets reinitialized when the number of rates or even the hardware mode is changed? Mattias - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
