linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ian Kent <raven@themaw.net>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	Brian Foster <bfoster@redhat.com>,
	Eric Sandeen <sandeen@sandeen.net>,
	David Howells <dhowells@redhat.com>,
	Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH v5 05/17] xfs: mount-api - refactor suffix_kstrtoint()
Date: Wed, 9 Oct 2019 17:03:10 +0100	[thread overview]
Message-ID: <20191009160310.GA26530@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20191009152911.GA30439@infradead.org>

On Wed, Oct 09, 2019 at 08:29:11AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 09, 2019 at 04:21:27PM +0100, Al Viro wrote:
> > What we need to do is to turn fs_parameter_type into a pointer
> > to function.  With fs_param_is_bool et.al. becoming instances
> > of such, and fs_parse() switch from hell turning into
> > 	err = p->type(p, param, result);
> > 
> > That won't affect the existing macros or any filesystem code.
> > If some filesystem wants to have helpers of its own - more
> > power to it, just use __fsparam(my_bloody_helper, "foo", Opt_foo, 0)
> > and be done with that.
> 
> Actually, while we could keep the old macros around at least
> temporarily for existing users I think killing them actually would
> improve the file systems as well.
> 
> This:
> 
> static const struct fs_parameter_spec afs_param_specs[] = {
> 	{ "autocell",	Opt_autocell,	fs_parse_flag },
> 	{ "dyn",	Opt_dyn,	fs_parse_flag },
> 	{ "flock",	Opt_flock,	fs_parse_enum },
> 	{ "source",	Opt_source,	fs_parse_string },
>         {}
> };
> 
> 
> is a lot more obvious than:
> 
> static const struct fs_parameter_spec afs_param_specs[] = {
>         fsparam_flag  ("autocell",      Opt_autocell),
>         fsparam_flag  ("dyn",           Opt_dyn),
>         fsparam_enum  ("flock",         Opt_flock),
>         fsparam_string("source",        Opt_source),
>         {}
> };

Except that I want to be able to have something like
-       fsparam_enum   ("errors",             Opt_errors),
+       fsparam_enum   ("errors",             Opt_errors, gfs2_param_errors),
with
+static const struct fs_parameter_enum gfs2_param_errors[] = {
+       {"withdraw",   Opt_errors_withdraw },
+       {"panic",      Opt_errors_panic },
+       {}
+};
instead of having them all squashed into one array, as in
-static const struct fs_parameter_enum gfs2_param_enums[] = {
-       { Opt_quota,    "off",        Opt_quota_off },
-       { Opt_quota,    "account",    Opt_quota_account },
-       { Opt_quota,    "on",         Opt_quota_on },
-       { Opt_data,     "writeback",  Opt_data_writeback },
-       { Opt_data,     "ordered",    Opt_data_ordered },
-       { Opt_errors,   "withdraw",   Opt_errors_withdraw },
-       { Opt_errors,   "panic",      Opt_errors_panic },
...
 const struct fs_parameter_description gfs2_fs_parameters = {
        .name = "gfs2",
        .specs = gfs2_param_specs,
-       .enums = gfs2_param_enums,
 };

IOW, I want to kill ->enums thing.  And ->name is also trivial
to kill, at which point we are left with just what used to be
->specs.

Another thing is, struct fs_parameter_enum becomes pretty
much identical to struct constant_table and can be folded into it.

I have some experiments in that direction (very incomplete right
now) in #work.mount-parser-later; next cycle fodder, I'm afraid.

	Another thing is, consider something like "it's an
integer in range from 2 to 36".  Fairly useful in many cases,
and we could do helpers for that.  Except that they need a pointer
to helper-private data (the limits)...

	These macros somewhat isolate the filesystems until the
things settle down.  And one needs examples of conversions to
see what's missing - inventing a grand scheme out of thin air
doesn't work...

  reply	other threads:[~2019-10-09 16:03 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 11:30 [PATCH v5 00/17] xfs: mount API patch series Ian Kent
2019-10-09 11:30 ` [PATCH v5 01/17] vfs: Create fs_context-aware mount_bdev() replacement Ian Kent
2019-10-09 11:30 ` [PATCH v5 02/17] vfs: add missing blkdev_put() in get_tree_bdev() Ian Kent
2019-10-09 11:30 ` [PATCH v5 03/17] xfs: remove very old mount option Ian Kent
2019-10-09 11:30 ` [PATCH v5 04/17] xfs: mount-api - add fs parameter description Ian Kent
2019-10-09 14:48   ` Christoph Hellwig
2019-10-10  0:56     ` Ian Kent
2019-10-10  6:39       ` Christoph Hellwig
2019-10-10  8:31         ` Ian Kent
2019-10-09 14:53   ` Christoph Hellwig
2019-10-09 11:30 ` [PATCH v5 05/17] xfs: mount-api - refactor suffix_kstrtoint() Ian Kent
2019-10-09 14:48   ` Christoph Hellwig
2019-10-09 15:21     ` Al Viro
2019-10-09 15:29       ` Christoph Hellwig
2019-10-09 16:03         ` Al Viro [this message]
2019-10-09 18:01           ` Christoph Hellwig
2019-10-09 18:22             ` Al Viro
2019-12-06  8:27               ` Christoph Hellwig
2019-10-10  0:59     ` Ian Kent
2019-10-09 11:30 ` [PATCH v5 06/17] xfs: mount-api - refactor xfs_parseags() Ian Kent
2019-10-09 14:56   ` Christoph Hellwig
2019-10-10  1:08     ` Ian Kent
2019-10-09 11:30 ` [PATCH v5 07/17] xfs: mount-api - make xfs_parse_param() take context .parse_param() args Ian Kent
2019-10-09 11:30 ` [PATCH v5 08/17] xfs: mount-api - move xfs_parseargs() validation to a helper Ian Kent
2019-10-09 15:02   ` Christoph Hellwig
2019-10-09 19:47     ` Darrick J. Wong
2019-10-10  6:38       ` Christoph Hellwig
2019-10-10  7:57         ` Christoph Hellwig
2019-10-09 11:30 ` [PATCH v5 09/17] xfs: mount-api - refactor xfs_fs_fill_super() Ian Kent
2019-10-09 15:03   ` Christoph Hellwig
2019-10-10  1:10     ` Ian Kent
2019-10-09 11:31 ` [PATCH v5 10/17] xfs: mount-api - add xfs_get_tree() Ian Kent
2019-10-09 15:04   ` Christoph Hellwig
2019-10-10  1:11     ` Ian Kent
2019-10-09 11:31 ` [PATCH v5 11/17] xfs: mount-api - add xfs_remount_rw() helper Ian Kent
2019-10-09 11:31 ` [PATCH v5 12/17] xfs: mount-api - add xfs_remount_ro() helper Ian Kent
2019-10-09 11:31 ` [PATCH v5 13/17] xfs: mount api - add xfs_reconfigure() Ian Kent
2019-10-09 12:51   ` Brian Foster
2019-10-09 15:05   ` Christoph Hellwig
2019-10-10  1:12     ` Ian Kent
2019-10-09 11:31 ` [PATCH v5 14/17] xfs: mount-api - add xfs_fc_free() Ian Kent
2019-10-09 12:51   ` Brian Foster
2019-10-09 11:31 ` [PATCH v5 15/17] xfs: mount-api - dont set sb in xfs_mount_alloc() Ian Kent
2019-10-09 11:31 ` [PATCH v5 16/17] xfs: mount-api - switch to new mount-api Ian Kent
2019-10-09 15:10   ` Christoph Hellwig
2019-10-10  1:15     ` Ian Kent
2019-10-09 11:31 ` [PATCH v5 17/17] xfs: mount-api - remove remaining legacy mount code Ian Kent
2019-10-09 15:10   ` Christoph Hellwig
2019-10-10  1:17     ` Ian Kent
2019-10-09 14:52 ` [PATCH v5 00/17] xfs: mount API patch series Christoph Hellwig
2019-10-14  1:28   ` Ian Kent

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=20191009160310.GA26530@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bfoster@redhat.com \
    --cc=dchinner@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=sandeen@sandeen.net \
    /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).