On Fri, Apr 1, 2022 at 2:25 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>
> I was recently working on a patch for krbd, and was dismayed to discover
> that the rbd tool wouldn't pass through a new kernel option that I had
> added. Looking at the code, we have a lot off places where we just
> "hand-off" options to the kernel, and then we return -EINVAL on anything
> that the userland program doesn't know about:
>
> } else if (!strcmp(this_char, "udev") || !strcmp(this_char, "noudev")) {
> put_map_option("udev", this_char, map_options);
> } else {
> std::cerr << "rbd: unknown map option '" << this_char << "'" << std::endl;
> return -EINVAL;
> }
>
> Kernel mount helper programs usually just pass through options that they
> don't recognize, so we (usually) don't need to deploy both a new kernel
> and userspace program to use a new mount option.
Hi Jeff,
This was added way back in Firefly days after fixing a particular
backwards compatibility issue. I think the idea was to reserve the
ability to hide some "unfavored" kernel options in the future. We
never used it for that and in hindsight it was a rather misguided
intention.
>
> Is there any reason not to just pass through krbd options that the
> parser doesn't recognize? The kernel parser should be able to reject the
> mapping with EINVAL just as easily (though you would lose the ability to
> report which option it choked on to stderr).
I have actually been meaning to do exactly that probably for a few of
years now -- feel free to raise a PR ;)
Thanks,
Ilya
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
