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.
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).
--
Jeff Layton <jlayton@xxxxxxxxxx>
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
