On 12/17/19 9:36 PM, Al Viro wrote:
> On Fri, Dec 06, 2019 at 10:31:57AM -0600, Eric Sandeen wrote:
>> There doesn't seem to be a strong reason to have a copy of the
>> filesystem name string in the fs_parameter_description structure;
>> it's easy enough to get the name from the fs_type, and using it
>> instead ensures consistency across messages (for example,
>> vfs_parse_fs_param() already uses fc->fs_type->name for the error
>> messages, because it doesn't have the fs_parameter_description).
>
> Arrgh... That used to be fine. Now we have this:
> static int rbd_parse_param(struct fs_parameter *param,
> struct rbd_parse_opts_ctx *pctx)
> {
> struct rbd_options *opt = pctx->opts;
> struct fs_parse_result result;
> int token, ret;
>
> ret = ceph_parse_param(param, pctx->copts, NULL);
> if (ret != -ENOPARAM)
> return ret;
>
> token = fs_parse(NULL, rbd_parameters, param, &result);
> ^^^^
>
> Cthulhu damn it... And yes, that crap used to work.
> Frankly, I'm tempted to allocate fs_context in there (in
> rbd_parse_options(), or in rbd_add_parse_args()) - we've other
> oddities due to that...
>
> Alternatively, we could provide __fs_parse() that
> would take name as a separate argument and accepted NULL fc,
> with fs_parse() being a wrapper for that.
>
> *grumble*
FYI be careful if you do munge this in, V2 inexplicably killed the name in
the fs_type for afs. V3 fixed that thinko or whatever it was.
-Eric
