Messages in this thread | | | Date | Thu, 11 Mar 2021 14:28:14 +0100 | From | Jessica Yu <> | Subject | Re: [PATCH v2 2/2] modules: add CONFIG_MODPROBE_PATH |
| |
+++ Rasmus Villemoes [09/03/21 22:17 +0100]: >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>
Acked-by: Jessica Yu <jeyu@kernel.org>
Thanks!
| |