linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Mike Fleetwood <mike.fleetwood@googlemail.com>,
	Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
	David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features
Date: Tue, 24 Nov 2015 15:21:19 -0500	[thread overview]
Message-ID: <5654C6BF.8010502@gmail.com> (raw)
In-Reply-To: <CAMU1PDita6iet1xg97RfCDPWuVUaq=dYBO_eM3ZDQtvLRPcHCw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On 2015-11-24 09:39, Mike Fleetwood wrote:
> On 23 November 2015 at 12:56, Anand Jain <anand.jain@oracle.com> wrote:
>> In the newer kernel, supported kernel features can be known from
>>    /sys/fs/btrfs/features
>> however this interface was introduced only after 3.14, and most the
>> incompatible FS features were introduce before 3.14.
>>
>> This patch proposes to maintain kernel version against the feature list,
>> and so that will be the minimum kernel version needed to use the feature.
>>
>> Further, for features supported later than 3.14 this list can still be
>> updated, so it serves as a repository which can be displayed for easy
>> reference.
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>> v2: Check for condition that what happens when we fail to read kernel
>>      version. Now the code will fail back to use the default as set by
>>      the progs.
>>
>>   utils.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
>>   utils.h |  1 +
>>   2 files changed, 76 insertions(+), 5 deletions(-)
>>
>> diff --git a/utils.c b/utils.c
>> index b754686..24042e5 100644
>> --- a/utils.c
>> +++ b/utils.c
>> @@ -32,10 +32,12 @@
>>   #include <linux/loop.h>
>>   #include <linux/major.h>
>>   #include <linux/kdev_t.h>
>> +#include <linux/version.h>
>>   #include <limits.h>
>>   #include <blkid/blkid.h>
>>   #include <sys/vfs.h>
>>   #include <sys/statfs.h>
>> +#include <sys/utsname.h>
>>   #include <linux/magic.h>
>>
>>   #include "kerncompat.h"
>> @@ -567,21 +569,28 @@ out:
>>          return ret;
>>   }
>>
>> +/*
>> + * min_ker_ver: update with minimum kernel version at which the feature
>> + * was integrated into the mainline. For the transit period, that is
>> + * feature not yet in mainline but in mailing list and for testing,
>> + * please use "0.0" to indicate the same.
>> + */
>>   static const struct btrfs_fs_feature {
>>          const char *name;
>>          u64 flag;
>>          const char *desc;
>> +       const char *min_ker_ver;
>>   } mkfs_features[] = {
>>          { "mixed-bg", BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS,
>> -               "mixed data and metadata block groups" },
>> +               "mixed data and metadata block groups", "2.7.31"},
> I think you mean 2.6.37 here.
> 67377734fd24c3 "Btrfs: add support for mixed data+metadata block groups"
This brings up a rather important question:
Should compat-X.Y mean features that were considered usable in that 
version, or everything that version offered?  I understand wanting 
consistency with the kernel versions, but we shouldn't be creating 
filesystems that we know will break on the specified kernel even if it 
is mountable on it.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-11-24 20:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 12:56 [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version Anand Jain
2015-11-23 12:56 ` [PATCH v2 1/5] btrfs-progs: introduce framework to check kernel supported features Anand Jain
2015-11-24 14:39   ` Mike Fleetwood
2015-11-24 20:21     ` Austin S Hemmelgarn [this message]
2015-11-26 17:38       ` David Sterba
2015-11-30 12:30         ` Austin S Hemmelgarn
2015-11-25 10:58   ` [PATCH v3 " Anand Jain
2015-11-23 12:56 ` [PATCH v2 2/5] btrfs-progs: add framework to check features supported by sysfs Anand Jain
2015-11-23 12:56 ` [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs Anand Jain
2015-11-23 15:57   ` Christoph Anton Mitterer
2015-11-23 16:05     ` Austin S Hemmelgarn
2015-11-23 16:14       ` Christoph Anton Mitterer
2015-11-23 16:55         ` Austin S Hemmelgarn
2015-11-23 12:56 ` [PATCH v2 4/5] btrfs-progs: kernel based default features for btrfs-convert Anand Jain
2015-11-23 12:56 ` [PATCH 5/5] btrfs-progs: add warning when we fail to read sysfs or version Anand Jain
2015-11-23 17:56 ` [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version David Sterba
2015-11-23 20:14   ` Austin S Hemmelgarn
2015-11-24  6:29     ` Duncan
2015-11-24 13:22   ` Anand Jain
2015-12-04  1:44   ` Liu Bo
2015-12-04  2:08     ` Qu Wenruo
2015-12-04  2:53       ` Liu Bo
2015-12-04  3:57         ` Qu Wenruo
2015-12-04 18:23           ` Liu Bo
2015-12-04 14:19       ` David Sterba
2015-12-05  5:12         ` Anand Jain
2015-11-24 13:04 ` Anand Jain
2016-11-08 13:14 ` Anand Jain
2016-11-14 12:13   ` David Sterba
2016-11-22  8:54     ` Anand Jain
2016-11-22 13:16       ` David Sterba
2016-11-23  3:00         ` Anand Jain
2016-11-23 10:31           ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5654C6BF.8010502@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=mike.fleetwood@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).