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.
> IIRC, I suggest to maintain similar feature matrix in fstests, but Dave pointed out the above problem.
>
> So I'm not fan of reading kernel version and generate supported features for that.
>
> IMHO, just use /sys/fs/btrfs/features is good enough.
*nod*
> And if there is no such file, just ignore it, user is responsible for
> such case.
Yep, 3.14 was over a year and a half ago, I don't see much point in
hardcoding kernel versions for such old kernels in the current
upstream codebase.
The only kernels that old still running are likely distro kernels, and
they can solve this problem by backporting the /sys/fs/btrfs/features
patch.
-Eric
> Thanks,
> Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
