On Tue, 14 Jan 2020 06:37:03 +0100, Martin Schiller wrote:
>> diff --git a/include/uapi/linux/hdlc/ioctl.h
>> b/include/uapi/linux/hdlc/ioctl.h
>> index 0fe4238e8246..3656ce8b8af0 100644
>> --- a/include/uapi/linux/hdlc/ioctl.h
>> +++ b/include/uapi/linux/hdlc/ioctl.h
>> @@ -3,7 +3,7 @@
>> #define __HDLC_IOCTL_H__
>>
>>
>> -#define GENERIC_HDLC_VERSION 4 /* For synchronization with sethdlc
>> utility */
>> +#define GENERIC_HDLC_VERSION 5 /* For synchronization with sethdlc
>> utility */
>
> What's the backward compatibility story in this code?
Well, I thought I have to increment the version to keep the kernel code
and the sethdlc utility in sync (like the comment says).
Perhaps I chose the wrong place for asking this question, IOCTL code
was my real worry. I don't think this version number is validated so
I think bumping it shouldn't break anything?
> The IOCTL handling at least looks like it may start returning errors
> to existing user space which could have expected the parameters to
> IF_PROTO_X25 (other than just ifr_settings.type) to be ignored.
I could also try to implement it without incrementing the version by
looking at ifr_settings.size and using the former defaults if the size
doesn't match.
Sounds good, thank you!