On Wed, Oct 09, 2019 at 07:48:59AM -0700, Christoph Hellwig wrote: > On Wed, Oct 09, 2019 at 07:30:36PM +0800, Ian Kent wrote: > > The mount-api doesn't have a "human unit" parse type yet so > > the options that have values like "10k" etc. still need to > > be converted by the fs. > > Any reason you don't lift it to the the core mount api code? The garbage enum fs_parameter_type thing. Once we kill that (and I *will* kill it), sure - it's a sufficiently common case to have helpers for it around. But until then I'll veto any further additions to that trash pile. Look at fs_parse() - every sodding value added to that enum turns into an extra case in a large switch. It's unsustainable in that form and I *really* don't want to be in position of gatekeeper deciding what is and what isn't sufficiently useful to go there. 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. The thing is, "here's a commonly useful helper, let's take it to fs/*.c" is much easier than "add a new constant to that global enum and a case to that ever-growing switch in fs_parser.c".
