Hi!

I struggled to perform changes to all parts that affected by my update to
ratectl api
and got the customized kernel compiled... I'm now tring to play it on my
AR9227 device.

Thanks!

Chenchong


On Sun, Aug 25, 2013 at 10:39 PM, Adrian Chadd <adr...@freebsd.org> wrote:

> Hi!
>
> Have you tried this out with any hardware just yet?
>
>
> -adrian
>
>
>
> On 25 August 2013 07:30, Chenchong Qin <qinchench...@gmail.com> wrote:
>
>> Hi!
>>
>> This is the latest update.
>>
>> * add a simple per vap ratectl statistic tracker and api to update it.
>> * port irn_capabilities to irs_capabilities in struct ieee80211_rc_stat.
>>   perhaps the capabilities field needs to be within ieee80211_rc_stat as
>>   a per vap atrribute. corresponding updates performed.
>> * add ieee80211_ratectl_none.h to record common ratectl state.
>>
>> Thanks!
>>
>> Chenchong
>>
>>
>> On Thu, Aug 15, 2013 at 8:03 PM, Chenchong Qin <qinchench...@gmail.com>wrote:
>>
>>> Hi!
>>>
>>> Here is my latest update. In this update:
>>>
>>> * add a new struct, ieee80211_ratectl_node. This is the common state
>>> that all per node rc
>>>   state, i.e. ieee80211_[amrr|sample]_node, should contains it as the
>>> first field. It's now used to store
>>>   the capabilities. see below.
>>> * rename ir_capabilities to irn_capabilities and move it to
>>> ieee80211_ratectl_node (it contained in
>>>   ieee80211_[amrr|sample]_node). ieee80211_ratectl is readonly, so
>>> ir_capabilities can't be set. And,
>>>   the capabilities is not a part of rc algo. It seems that it should be
>>> put in the per node rc state. Interface
>>>   of ieee80211_ratectl_node_init() and its callers  are updated.
>>> References to ir_capabilities are also adapted.
>>> * add ieee80211_ratectl_[node_is11n|get_rateset] to the ratectl api. rc
>>> algoes all need these functions.
>>> * change the naming conversion of IEEE80211_RATECTL_FLAG_*.
>>> * some errors fixed.
>>>
>>>
>>> On Thu, Aug 15, 2013 at 12:58 AM, Adrian Chadd <adr...@freebsd.org>wrote:
>>>
>>>> Hi!
>>>>
>>>> So yes, we do need to have a generic way of returning that completion
>>>> information to the rate control code.
>>>>
>>>> I'm all for you churning the rate control API to return a struct
>>>> ieee80211_rc_info in the complete function and totally just kill arg1/arg2.
>>>> That forces us to extend ieee80211_rc_info to be "right" for all the
>>>> drivers.
>>>>
>>>
>>> Do you mean drop arg1/arg2 and pass pointer of ieee80211_rc_info to the
>>> complete function directly? Or return it
>>> when complete function return?
>>>
>>>
>>>> What wifi devices do you have there? It looks like we're almost at the
>>>> point where we can start converting a few things to use the modified rate
>>>> control API and modules - notably iwn (which won't use the multi-rate retry
>>>> stuff to begin with - it works "differently"..) and ath (which will use the
>>>> multi-rate retry stuff and the sample rate control module.)
>>>>
>>>
>>> Yeah, I have an AR9227 device at hand.
>>>
>>> And, I also get a question here. The ieee80211_ratetable doesn't get a
>>> rateCode field. So, how we get the
>>>  ratecode of the non_ht rate?
>>>
>>> Thanks!
>>>
>>> Chenchong
>>>
>>>
>>
>
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to