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 ?
Otherwise progs will assume all features are supported as in
the current design.
Thanks, Anand
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
