On Sat, Mar 13, 2021 at 10:25:28PM +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 made the initramfs unpacking asynchronous - 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. > > Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Acked-by: Jessica Yu <j...@kernel.org> > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk>
Acked-by: Luis Chamberlain <mcg...@kernel.org> Luis