On 2013-02-28 7:53 PM, Adrian Chadd wrote: > On 28 February 2013 05:09, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > >>> The same could be said of PID... >> I agree, we should remove that one as well. > > One of the advantages of having multiple RC modules - even if they're > not longer optimal - is to keep the API honest. :-) > > I still keep onoe/amrr working in FreeBSD's ath(4) driver, primarily > to make sure that I don't change the API without thinking too much > about what other rate control modules do, but also to provide a > simpler example of how the API works. In that case I'd rather keep PID than the ath9k rate control. The ath9k rate control is a horrible example of how to use the rate control API, and fixing that is a waste of time in my opinion. By the way, minstrel and minstrel_ht are two mostly separate implementations using the same API, except for the fact that minstrel_ht falls back to minstrel for legacy clients. So we already do have multiple examples here :) > Personally, I'd like to see more examples of rate control modules in > LInux/FreeBSD, especially ones that start demanding more 802.11 state > (ie, air-time QoS.) Do you have any good ideas on what state information would be useful for a rate control to demand? - Felix -- 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
