On 24.06.20 г. 15:17 ч., Johannes Thumshirn wrote:
> On 24/06/2020 14:14, Hans van Kranenburg wrote:
> [...]
>> Random idea... What if an imaginary me likes building kernels with
>> random features from the future (e.g. on top of 4.19LTS), and the next
>> feature added is to show the value of the new flapsie field.
>>
>> The 'version' will increase, but I decide to not pick the new csum type
>> patches because I don't need them, I only pick the new flapsie feature.
>
> Then csum_type will be 0, which is crc32c. But this works by accident.
>
>> Now, how does my userspace tooling know that the u16 flapsie field has a
>> meaning but the csum_type hasn't?
>>
>> ("You shouldn't do that" is also a possible answer...)
>
> While it's a possible answer, I admit your concerns are valid. That can be
> handled easier by a flags field.
I agree, basically having a monotonically incrementing counter implies
there is a dependency between previous features and currently added one.
Whereas with a flag you just get information about what features are
supported without any implied dependencies. The flags interface is IMO a
better interface which gives the user less freedom to shoot themselves
in the foot. OTOH when one starts doing out of tree backports then one
is responsible to maintain them.
So the answer could go both ways, but this doesn't mean we shouldn't
strive to build better/more robust interfaces.
>
> Thanks,
> Johannes
>
>
