On 10/21/15 9:49 AM, Anand Jain wrote:
>
>
> On 10/21/2015 10:41 PM, Eric Sandeen wrote:
>> On 10/21/15 4:09 AM, Qu Wenruo wrote:
>>>> +static int get_kernel_code()
>>>> +{
>>>> + int ret;
>>>> + struct utsname utsbuf;
>>>> + char *version;
>>>> +
>>>> + ret = uname(&utsbuf);
>>>> + if (ret)
>>>> + return -ret;
>>>> +
>>>> + version = strtok(utsbuf.release, "-");
>>>> +
>>>> + return version_to_code(version);
>>>> +}
>>>
>>> The only problem is, kernel version is never reliable.
>>> If someone wants, uname output may even contain no numeric value.
>>
>> yep, I agree. This will be misery for any custom kernel.
>
> How if we apply this only when kernel version is available ?
The problem is "kernel version" may not match btrfs version.
Distros backport and update subsystems without changing the
kernel version.
> Otherwise progs will assume all features are supported as in
> the current design.
>
> Thanks, Anand
This is only a concern for kernels prior to 3.14, right?
v3.13 was released Sun Jan 19 18:40:23 2014, almost 2 years ago.
What has raised the current concern about these old kernels?
Why does this need fixing in upstream code?
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
