>> Also separated the conditions
>> + if ((len <= 0) ||
>> + (!tfrc_lh_closed_check(cur,
>> cong_evt->tfrchrx_ccval))) {
>> back into
>> if (len <= 0)
>> return false;
>>
>> if (!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval))
>> return false;
>>
>
> Thanks!
Yes I know, the above change is reintroduced by patch 2/2. Only found
out after I had gone through this one.
>> The following function pokes a hole in thei so far "abstract" data type;
>> the convention has been to access the internals of the struct only via
>> get-functions:
>>
>> static inline struct tfrc_loss_interval
>> *tfrc_lh_get_loss_interval(struct tfrc_loss_hist *lh, const u8 i)
>> {
>> BUG_ON(i >= lh->counter);
>> return lh->ring[LIH_INDEX(lh->counter - i - 1)];
>> }
>>
>> (You use it in patch 3/5 to gain access to li_ccval and li_losses.
>> Better would be to have two separate accessor functions.)
>>
>
> Okay, I will fix this.
>
It would be great but is secondary at this stage. The primary objective
should be to get a common prototype out soon, and then verify that it is
correct. I expect several rewrites of other code to make this possible,
so the above detail can also be fixed once a prototype has been found to
work satisfactorily.
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Kernel]
[IETF DCCP]
[Linux Networking]
[Git]
[Security]
[Linux Assembly]
[Bugtraq]
[Photo]
[Yosemite]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Linux SCSI]
[Linux Resources]