On 14-2-2017 21:11, Johannes Berg wrote:
> On Tue, 2017-02-14 at 21:09 +0100, Arend Van Spriel wrote:
>> On 14-2-2017 14:12, Johannes Berg wrote:
>>> On Tue, 2017-02-14 at 14:07 +0100, Arend Van Spriel wrote:
>>>
>>>>> No. But there was a size limit on how much older userspace
>>>>> could
>>>>> process before we did the splitting.
>>>>
>>>> I see. So basically adding stuff to (split_start == 0) is not
>>>> wanted.
>>>
>>> Correct.
>>
>> Uhm. Now I am staring at the code there and wonder about following.
>> Up until (split_start == 7) I see:
>>
>> state->split_start++;
>> if (state->split)
>> break;
>>
>> For the remaining cases the break is unconditional. Any idea how to
>> interpret that?
>
> Yeah, actually, adding stuff to anything where split_start < 7 is
> therefore not wanted :-)
>
> The thing is that we if no split is accepted by the userspace tool
> (state->split is false) then we have to send everything in one big
> message. This is everything until split_start == 7, I guess.
>
> After that, there's only new stuff that such old userspace will be
> unable to interpret anyway, so the break is then unconditional - old
> userspace without split will never see those new capabilities, and new
> userspace can deal with the split.
Ok. Now I bumped into a nice comment which I should have seen earlier ;-)
/*
* Any information below this point is only available to
* applications that can deal with it being split. This
* helps ensure that newly added capabilities don't break
* older tools by overrunning their buffers.
*
* We still increment split_start so that in the split
* case we'll continue with more data in the next round,
* but break unconditionally so unsplit data stops here.
*/
state->split_start++;
break;
case 9:
Oh, well. So actually the sched_scan_plan attributes in case 0 slipped
through the cracks.
Regards,
Arend
