All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com, "Dave Chinner" <dchinner@redhat.com>,
	"Jan Ťulák" <jtulak@redhat.com>
Subject: Re: [PATCH 13/17] mkfs: encode conflicts into parsing table
Date: Tue, 30 Jun 2015 13:57:36 +1000	[thread overview]
Message-ID: <20150630035736.GJ7943@dastard> (raw)
In-Reply-To: <20150626171730.GI40750@bfoster.bfoster>

On Fri, Jun 26, 2015 at 01:17:31PM -0400, Brian Foster wrote:
> On Fri, Jun 19, 2015 at 01:02:02PM +0200, Jan Ťulák wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > Many options conflict, so we need to specify which options conflict
> > with each other in a generic manner. We already have a "seen"
> > variable used for respecification detection, so we can also use this
> > code conflict detection. Hence add a "conflicts" array to the sub
> > options parameter definition.
.....
> > @@ -2020,7 +2027,7 @@ _("cannot specify both -m crc=1 and -n ftype\n"));
> >  						  &value)) {
> >  				case S_LOG:
> >  				case S_SECTLOG:
> > -					if (ssflag || lssflag)
> > +					if (lssflag)
> >  						conflict('s', subopts,
> >  							 S_SECTSIZE, S_SECTLOG);
> >  					sectorlog = getnum(value, &sopts,
> > @@ -2032,7 +2039,7 @@ _("cannot specify both -m crc=1 and -n ftype\n"));
> >  					break;
> >  				case S_SIZE:
> >  				case S_SECTSIZE:
> > -					if (slflag || lslflag)
> > +					if (lslflag)
> >  						conflict('s', subopts, S_SECTLOG,
> >  							 S_SECTSIZE);
> 
> Hmm.. so is the limitation here that we can't do generic conflict
> detection across different option structs? If so, I suppose that's not
> the end of the world. The cleanup is still well worth it.

I just never got around to coding it in a generic fashion - I didn't
finish the entire patchset back when I originally wrote it....

> I wonder if we
> still need to set lslflag/lssflag in either of the above cases, though.
> It seems like the generic detection should handle it..?

In the end it would look at the relevant ->seen flag to determine
if there was a cross-option-struct conflict. Essentially, the
conflict definition needs to define conflicts via a {group, option}
tuple rather than just the {option} it uses now...

-Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-06-30  3:57 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 11:01 [PATCH 00/17] mkfs: sanitise input parameters Jan Ťulák
2015-06-19 11:01 ` [PATCH 01/17] xfsprogs: use common code for multi-disk detection Jan Ťulák
2015-06-19 11:10   ` Christoph Hellwig
2015-06-19 11:51     ` Jan Tulak
2015-06-25 19:37   ` Brian Foster
2015-07-02 12:47     ` Jan Tulak
2015-07-02 14:14       ` Brian Foster
2015-07-02 23:05         ` Dave Chinner
2015-07-03 13:22           ` Brian Foster
2015-07-08 16:14           ` Jan Tulak
2015-07-09  0:45             ` Dave Chinner
2015-07-09  8:24               ` Jan Tulak
2015-07-03 10:06         ` Jan Tulak
2015-06-19 11:01 ` [PATCH 02/17] mkfs: sanitise ftype parameter values Jan Ťulák
2015-06-25 19:37   ` Brian Foster
2015-06-19 11:01 ` [PATCH 03/17] mkfs: Sanitise the superblock feature macros Jan Ťulák
2015-06-25 19:38   ` Brian Foster
2015-07-03  9:53     ` Jan Tulak
2015-07-03 13:24       ` Brian Foster
2015-06-19 11:01 ` [PATCH 04/17] mkfs: validate all input values Jan Ťulák
2015-06-25 19:38   ` Brian Foster
2015-06-19 11:01 ` [PATCH 05/17] mkfs: factor boolean option parsing Jan Ťulák
2015-06-25 19:38   ` Brian Foster
2015-06-19 11:01 ` [PATCH 06/17] mkfs: validate logarithmic parameters sanely Jan Ťulák
2015-06-26 17:16   ` Brian Foster
2015-06-19 11:01 ` [PATCH 07/17] mkfs: structify input parameter passing Jan Ťulák
2015-06-26 17:16   ` Brian Foster
2015-06-19 11:01 ` [PATCH 08/17] mkfs: getbool is redundant Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-30  1:32     ` Dave Chinner
2015-06-19 11:01 ` [PATCH 09/17] mkfs: use getnum_checked for all ranged parameters Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-19 11:01 ` [PATCH 10/17] mkfs: add respecification detection to generic parsing Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-19 11:02 ` [PATCH 11/17] mkfs: table based parsing for converted parameters Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-19 11:02 ` [PATCH 12/17] mkfs: merge getnum Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-19 11:02 ` [PATCH 13/17] mkfs: encode conflicts into parsing table Jan Ťulák
2015-06-26 17:17   ` Brian Foster
2015-06-30  3:57     ` Dave Chinner [this message]
2015-06-30 11:27       ` Brian Foster
2015-07-01  8:30         ` Jan Tulak
2015-06-19 11:02 ` [PATCH 14/17] mkfs: add string options to generic parsing Jan Ťulák
2015-06-26 19:32   ` Brian Foster
2015-06-19 11:02 ` [PATCH 15/17] mkfs: don't treat files as though they are block devices Jan Ťulák
2015-06-26 19:32   ` Brian Foster
2015-06-19 11:02 ` [PATCH 16/17] mkfs fix: handling of files Jan Ťulák
2015-06-26 19:32   ` Brian Foster
2015-06-19 11:02 ` [PATCH 17/17] mkfs: move spinodes crc check Jan Ťulák
2015-06-26 19:32   ` Brian Foster

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=20150630035736.GJ7943@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=dchinner@redhat.com \
    --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.