From: Eric Sandeen <sandeen@sandeen.net>
To: Jan Tulak <jtulak@redhat.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 03/19] mkfs: Sanitise the superblock feature macros
Date: Thu, 7 Apr 2016 08:18:17 -0500 [thread overview]
Message-ID: <57065E19.9070401@sandeen.net> (raw)
In-Reply-To: <CACj3i72K0JHkGKES8eintQ=+rbN7hrSQc3+BNQ2eHfZtm7ik4g@mail.gmail.com>
On 4/7/16 8:09 AM, Jan Tulak wrote:
>
...
> On Thu, Apr 7, 2016 at 3:43 AM, Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>> wrote:
>
> > @@ -981,11 +1077,21 @@ main(
> > int worst_freelist;
> > libxfs_init_t xi;
> > struct fs_topology ft;
> > - int lazy_sb_counters;
> > - int crcs_enabled;
> > - int finobt;
> > - bool finobtflag;
> > - int spinodes;
> > + struct sb_feat_args sb_feat = {
> > + .finobt = 1,
> > + .finobtflag = false,
>
>
> should we really have "finobtflag" in this structure?
> This structure should only carry feature selections, not feature
> specification flags I think. Why is this the only such flag
> in the structure?
>
> Pretty sure finobtflag should stay a variable for now
> just like lvflag (which goes with log_version).
>
>
> It might be right to move it out, but the flag is removed few
> patches later entirely. Is it worth of the work? I would say nah, let
> it die where it is. :-)
Given that it doesn't seem to be a bug, I guess that might be ok,
but in general introducing incorrect things and fixing them later
in the series is strongly discouraged...
>
>
> ...
>
> > @@ -1517,7 +1617,14 @@ main(
> > c = atoi(value);
> > if (c < 0 || c > 1)
> > illegal(value, "m crc");
> > - crcs_enabled = c;
> > + if (c && nftype) {
> > + fprintf(stderr,
> > +_("cannot specify both crc and ftype\n"));
> > + usage();
>
> hm, why is conflict checking added? It's not what the commit says
> the patch does.
>
> It also regresses the bug I fixed in
>
> commit b990de8ba4e2df2bc76a140799d3ddb4a0eac4ce
> Author: Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>>
> Date: Tue Aug 18 17:53:17 2015 +1000
>
> mkfs.xfs: fix ftype-vs-crc option combination testing
>
> with this patch, it is broken again:
>
> # mkfs/mkfs.xfs -m crc=0 -n ftype=1 -dfile,name=fsfile,size=16g
> <success>
> # mkfs/mkfs.xfs -n ftype=1 -m crc=0 -dfile,name=fsfile,size=16g
> cannot specify both crc and ftype
> Usage: mkfs.xfs
> ...
>
> Because the patch is much older than your fix, and at the time it
> was created, it is possible that there wasn't any such check... I
> would call it the risk of necromancy. :-)
Most likely a forward-port or merge error I think.
> Anyway, I already fixed this issue in this cycle, and added the the
> ftype, crc order into a test checking for options sanity. Just I
> didn't submitted the change yet.
Ok, so it is fixed in your new version of this patch?
>
> ...
>
> > @@ -1879,23 +1988,25 @@ _("32 bit Project IDs always enabled on CRC enabled filesytems\n"));
> > } else {
> > /*
> > * The kernel doesn't currently support crc=0,finobt=1
> > - * filesystems. If crcs are not enabled and the user has
> > - * explicitly turned them off then silently turn them off
> > - * to avoid an unnecessary warning. If the user explicitly
> > - * tried to use crc=0,finobt=1, then issue a warning before
> > - * turning them off.
> > + * filesystems. If crcs are not enabled and the user has not
> > + * explicitly turned finobt on, then silently turn it off to
> > + * avoid an unnecessary warning. If the user explicitly tried
> > + * to use crc=0,finobt=1, then issue a warning before turning
> > + * them off.
> > */
> > - if (finobt && finobtflag) {
> > - fprintf(stderr,
> > -_("warning: finobt not supported without CRC support, disabled.\n"));
> > + if (sb_feat.finobt){
> > + if (sb_feat.finobtflag) {
> > + fprintf(stderr,
> > + _("warning: finobt not supported without CRC support, disabled.\n"));
> > + }
> > + sb_feat.finobt = 0;
>
> like I mentioned, just this, I think (assuming we like the silent turning
> off, but that would be a different patch):
>
>
> Merging the conditions is indeed cleaner.
>
> And I will change it to failure, if the conflicting options are given
> explicitly. Just a small patch adding "usage();" and removing
> "warning"...
Ok, so for this patch, nothing but the mechanical change matching all the others,
right? If there is any change in behavior to be done, that should be a different patch.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-04-07 13:18 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 11:15 [PATCH 00/19] mkfs cleaning jtulak
2016-03-24 11:15 ` [PATCH 01/19] xfsprogs: use common code for multi-disk detection jtulak
2016-03-31 20:25 ` Eric Sandeen
2016-04-06 9:05 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 02/19] mkfs: sanitise ftype parameter values jtulak
2016-03-24 16:33 ` Eric Sandeen
2016-03-29 16:11 ` Jan Tulak
2016-03-29 16:17 ` Eric Sandeen
2016-03-29 16:20 ` Jan Tulak
2016-03-29 17:14 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros jtulak
2016-04-01 2:05 ` Eric Sandeen
2016-04-06 9:12 ` Jan Tulak
2016-04-06 21:01 ` Dave Chinner
2016-04-07 11:53 ` Jan Tulak
2016-04-07 0:12 ` Eric Sandeen
2016-04-07 1:43 ` Eric Sandeen
2016-04-07 13:09 ` Jan Tulak
2016-04-07 13:18 ` Eric Sandeen [this message]
2016-04-07 13:27 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 04/19] mkfs: validate all input values jtulak
2016-04-06 23:02 ` Eric Sandeen
2016-04-07 11:15 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 05/19] mkfs: factor boolean option parsing jtulak
2016-04-07 2:48 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 06/19] mkfs: validate logarithmic parameters sanely jtulak
2016-04-07 2:52 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 07/19] mkfs: structify input parameter passing jtulak
2016-04-07 3:14 ` Eric Sandeen
2016-04-07 11:43 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 08/19] mkfs: getbool is redundant jtulak
2016-04-07 17:25 ` Eric Sandeen
2016-04-08 10:30 ` Jan Tulak
2016-04-08 17:41 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 09/19] mkfs: use getnum_checked for all ranged parameters jtulak
2016-04-07 19:02 ` Eric Sandeen
2016-04-08 10:47 ` Jan Tulak
2016-04-08 15:52 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 10/19] mkfs: add respecification detection to generic parsing jtulak
2016-04-07 19:06 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 11/19] mkfs: table based parsing for converted parameters jtulak
2016-04-07 19:08 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 12/19] mkfs: merge getnum jtulak
2016-04-07 19:14 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 13/19] mkfs: encode conflicts into parsing table jtulak
2016-04-07 22:40 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 14/19] mkfs: add string options to generic parsing jtulak
2016-04-07 22:49 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 15/19] mkfs: don't treat files as though they are block devices jtulak
2016-04-08 0:25 ` Eric Sandeen
2016-04-08 0:32 ` Eric Sandeen
2016-04-08 14:58 ` Jan Tulak
2016-04-08 15:50 ` Eric Sandeen
2016-04-08 15:56 ` Jan Tulak
2016-04-09 4:12 ` Eric Sandeen
2016-04-13 15:43 ` Jan Tulak
2016-04-14 9:49 ` Jan Tulak
2016-04-20 9:51 ` Jan Tulak
2016-04-20 13:17 ` Jan Tulak
2016-04-20 16:53 ` Eric Sandeen
2016-04-21 9:22 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 16/19] mkfs: move spinodes crc check jtulak
2016-03-24 11:15 ` [PATCH 17/19] xfsprogs: disable truncating of files jtulak
2016-04-06 21:42 ` Eric Sandeen
2016-04-07 9:41 ` Jan Tulak
2016-04-08 0:09 ` Dave Chinner
2016-04-08 10:06 ` Jan Tulak
2016-04-08 23:08 ` Dave Chinner
2016-04-13 15:08 ` Jan Tulak
2016-04-13 16:17 ` Eric Sandeen
2016-04-13 16:23 ` Jan Tulak
2016-04-13 16:25 ` Eric Sandeen
2016-04-13 21:37 ` Dave Chinner
2016-04-14 12:31 ` Jan Tulak
2016-03-24 11:15 ` [PATCH 18/19] mkfs: unit conversions are case insensitive jtulak
2016-04-06 21:10 ` Eric Sandeen
2016-04-07 10:50 ` Jan Tulak
2016-04-08 0:41 ` Eric Sandeen
2016-04-08 1:03 ` Dave Chinner
2016-04-08 9:08 ` Jan Tulak
2016-04-08 15:51 ` Eric Sandeen
2016-03-24 11:15 ` [PATCH 19/19] mkfs: add optional 'reason' for illegal_option jtulak
2016-04-06 22:23 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2016-04-21 9:39 [PATCH 00/19 v2] mkfs cleaning Jan Tulak
2016-04-21 9:39 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros Jan Tulak
2016-05-02 23:06 ` Eric Sandeen
2016-05-04 0:48 ` Eric Sandeen
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=57065E19.9070401@sandeen.net \
--to=sandeen@sandeen.net \
--cc=jtulak@redhat.com \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.