Re: [RFC V2 1/5] nl80211: allow multiple active scheduled scan requests

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

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