On 6/24/20 1:55 PM, Qu Wenruo wrote:
>
>
> On 2020/6/24 下午7:41, Johannes Thumshirn wrote:
>> On 24/06/2020 13:03, Qu Wenruo wrote:
>>>> diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
>>>> index e6b6cb0f8bc6..161d9100c2a6 100644
>>>> --- a/include/uapi/linux/btrfs.h
>>>> +++ b/include/uapi/linux/btrfs.h
>>>> @@ -250,10 +250,21 @@ struct btrfs_ioctl_fs_info_args {
>>>> __u32 nodesize; /* out */
>>>> __u32 sectorsize; /* out */
>>>> __u32 clone_alignment; /* out */
>>>> + __u32 flags; /* out */
>>> The flags looks a little too generic.
>>> What about extra_members or things like that?
>>>
>>> This flag really indicates what extra info the ioctl args can provide,
>>> so a better name would be easier to understand.
>>
>> Maybe version and for each new member it gets incremented?
>>
>
> That looks even better!
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.
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...)
Hans
