On Wed, 12 Jan 2000, David Woodhouse wrote:
> I'd be inclined to change request_module to take multiple arguments, but still
> to leave it defined as a NOP in the !CONFIG_KMOD case. That way, all the code
> gets cleaned up, but you don't incur the extra function call cost.
No, because that would make everything that includes kmod.h depend on
CONFIG_KMOD. The best way we found so far (based on Keith's suggestion) is
to have just one request_module() function which treats variable arguments
and is reduced to return -EINVAL if CONFIG_KMOD is not defined. This way
all the knowledge about CONFIG_KMOD is concentrated in kmod.c. Also,
kmod.h header should vanish and request_module() live in module.h
> I appreciate that the cost of that function call isn't exactly high - but it's
> not exactly necessary either. When you change to/from CONFIG_KMOD, you expect
> to have to recompile some files. It's not the end of the world.
It may well be the end of the world, if you only have 4 seconds to repair
some nuclear missile system (powered by Linux) and recompiling the whole
kernel will take 25.1 seconds if everything depends on CONFIG_KMOD....
> Except in exceptional cases, run-time performance is far more important than
> compilation time, surely?
those exceptional cases, e.g. loading a binary will be given a bit more
thought and performance analysis. If we find less than 0.01% degradation
then the beauty argument wins. (I hope).
regards,
Tigran.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:20 EST