On Wed, Oct 09, 2019 at 11:01:02AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 09, 2019 at 05:03:10PM +0100, Al Viro wrote:
> > 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
>
> Makes total sense and still fits the above scheme.
>
> > 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.
>
> Agreed.
>
> > I have some experiments in that direction (very incomplete right
> > now) in #work.mount-parser-later; next cycle fodder, I'm afraid.
>
> I like that a lot, and feel like we really shouldn't do more
> conversions until that ground work has been done
I'm not sure - for one thing, it's pretty much orthogonal to the
bulk of conversion; for another, I'm very sceptical about grand
schemes invented out of thin air in hope to cover everything in
the world, without finding out what _is_ there first.
Massaging the parser data structures can be done on top of the
other work just as well - the conflicts will be trivial to deal
with. And I'm perfectly fine with having the parser stuff
go in last, just prior to -rc1, so resolution will be my
headache.
Alternatively, I can do never-rebased short branch right now,
with the parts of changes likely to cause conflicts, so that
xfs, nfs, etc. work could pull it and be done with that.
Note that e.g. conversion of fs_is_... from enum members to
functions would require zero changes in filesystems. It would
allow to simplify them later on, but I would very much prefer
to do those extra helpers with converted codebase already
on hand.
