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
