Messages in this thread | | | Date | Wed, 10 Mar 2021 10:46:57 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH v2 2/2] modules: add CONFIG_MODPROBE_PATH |
| |
On Tue, Mar 09, 2021 at 10:17:00PM +0100, Rasmus Villemoes wrote: > Allow the developer to specifiy the initial value of the > modprobe_path[] string. This can be used to set it to the empty string > initially, thus effectively disabling request_module() during early > boot until userspace writes a new value via the > /proc/sys/kernel/modprobe interface. [1] > > When building a custom kernel (often for an embedded target), it's > normal to build everything into the kernel that is needed for booting, > and indeed the initramfs often contains no modules at all, so every > such request_module() done before userspace init has mounted the real > rootfs is a waste of time. > > This is particularly useful when combined with the previous patch, > which allowed the initramfs to be unpacked asynchronously - for that > to work, it had to make any usermodehelper call wait for the unpacking > to finish before attempting to invoke the userspace helper. By > eliminating all such (known-to-be-futile) calls of usermodehelper, the > initramfs unpacking and the {device,late}_initcalls can proceed in > parallel for much longer. > > For a relatively slow ppc board I'm working on, the two patches > combined lead to 0.2s faster boot - but more importantly, the fact > that the initramfs unpacking proceeds completely in the background > while devices get probed means I get to handle the gpio watchdog in > time without getting reset. > > [1] __request_module() already has an early -ENOENT return when > modprobe_path is the empty string. > > Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> > --- > init/Kconfig | 12 ++++++++++++ > kernel/kmod.c | 2 +- > 2 files changed, 13 insertions(+), 1 deletion(-)
Looks sane to me, odd we didn't think of doing this before.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| |