On Thu, Jul 25, 2024 at 9:59 PM Petr Pavlu <petr.pavlu@xxxxxxxx> wrote: > > On 7/22/24 12:23, Masahiro Yamada wrote: > > On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu <petr.pavlu@xxxxxxxx> wrote: > >> > >> The kernel configuration allows specifying a module compression mode. If > >> one is selected then each module gets compressed during > >> 'make modules_install' and additionally one can also enable support for > >> a respective direct in-kernel decompression support. This means that the > >> decompression support cannot be enabled without the automatic compression. > >> > >> Some distributions, such as the (open)SUSE family, use a signer service for > >> modules. A build runs on a worker machine but signing is done by a separate > >> locked-down server that is in possession of the signing key. The build > >> invokes 'make modules_install' to create a modules tree, collects > >> information about the modules, asks the signer service for their signature, > >> appends each signature to the respective module and compresses all modules. > >> > >> When using this arrangment, the 'make modules_install' step produces > >> unsigned+uncompressed modules and the distribution's own build recipe takes > >> care of signing and compression later. > >> > >> The signing support can be currently enabled without automatically signing > >> modules during 'make modules_install'. However, the in-kernel decompression > >> support can be selected only after first enabling automatic compression > >> during this step. > >> > >> To allow only enabling the in-kernel decompression support without the > >> automatic compression during 'make modules_install', separate the > >> compression options similarly to the signing options, as follows: > >> > >>> Enable loadable module support > >> [*] Module compression > >> Module compression type (GZIP) ---> > >> [*] Automatically compress all modules > >> [ ] Support in-kernel module decompression > >> > >> * "Module compression" (MODULE_COMPRESS) is a new main switch for the > >> compression/decompression support. It replaces MODULE_COMPRESS_NONE. > >> * "Module compression type" (MODULE_COMPRESS_<type>) chooses the > >> compression type, one of GZ, XZ, ZSTD. > >> * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new > >> option to enable module compression during 'make modules_install'. It > >> defaults to Y. > >> * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables > >> in-kernel decompression. > >> > >> Signed-off-by: Petr Pavlu <petr.pavlu@xxxxxxxx> > >> --- > > > > > > > > My preference is to add > > CONFIG_MODULE_DECOMPRESS_GZIP > > CONFIG_MODULE_DECOMPRESS_XZ > > CONFIG_MODULE_DECOMPRESS_ZSTD > > instead of > > CONFIG_MODULE_COMPRESS_ALL. > > > > > > > > > > For example, > > > > > > if MODULE_DECOMPRESS > > > > config MODULE_DECOMPRESS_GZIP > > bool "Support in-kernel GZIP decompression for module" > > default MODULE_COMPRESS_GZIP > > > > config MODULE_DECOMPRESS_XZ > > bool "Support in-kernel XZ decompression for module" > > default MODULE_COMPRESS_XZ > > > > config MODULE_DECOMPRESS_ZSTD > > bool "Support in-kernel ZSTD decompression for module" > > default MODULE_COMPRESS_ZSTD > > > > endif > > > > > > > > > > > > OR, maybe > > > > > > > > config MODULE_DECOMPRESS_GZIP > > bool "Support in-kernel GZIP decompression for module" > > select MODULE_DECOMPRESS > > > > config MODULE_DECOMPRESS_XZ > > bool "Support in-kernel XZ decompression for module" > > select MODULE_DECOMPRESS > > > > config MODULE_DECOMPRESS_ZSTD > > bool "Support in-kernel ZSTD decompression for module" > > select MODULE_DECOMPRESS > > > > config MODULE_DECOMPRESS > > bool > > > > > > > > > > You can toggle MODULE_COMPRESS_GZIP and > > MODULE_DECOMPRESS_GZIP independently > > I can implement this, but what would be a use case to enable multiple module > decompression types in the kernel? I just thought there is a possibility where the singer service A compresses modules in GZIP, and the singer service B in XZ, etc. If the compression type is predictable at the Kbuild time, it is fine. > > > > > > > Of course, the current kernel/module/decompress.c does not > > work when multiple (or zero) CONFIG_MODULE_DECOMPRESS_* is > > enabled. It needs a little modification. > > One issue is with the file /sys/module/compression which shows the module > decompression type supported by the kernel. If multiple types are allowed then > I think they should all get listed there. This could however create some > compatibility problems. For instance, kmod reads this file and currently > expects to find exactly one type, so it would need updating as well. OK, understood. Then, Acked-by: Masahiro Yamada <masahiroy@xxxxxxxxxx> -- Best Regards Masahiro Yamada
