On Thu, May 14, 2020 at 10:57:01PM +0930, Andrew Jeffery wrote:
> This is a step on the path to enabling kprobes, which depend on
> CONFIG_MODULES=y.
> 
> Setting CONFIG_MODULES=y results in the following change in kernel size:
> 
> Before:
>          $ size vmlinux
>             text    data     bss     dec     hex filename
>          8140500 2440582  178904 10759986         a42f32 vmlinux
>          $ stat --printf '%s\n' arch/arm/boot/zImage
>          3445200
> 
> After:
>          $ size vmlinux
>             text    data     bss     dec     hex filename
>          8240349 2388862  172304 10801515         a4d16b vmlinux
>          $ stat --printf '%s\n' arch/arm/boot/zImage
>          3458368
> 
> This gives a 41,529 byte increase to vmlinux and a 13,168 byte increase
> to the size of the compressed kernel image. In the most constrained BMC
> flash layout (arch/arm/boot/dts/openbmc-flash-layout.dtsi) this change
> decreases the free space in the kernel partition from 1,011,248 bytes to
> 998,080 bytes.
> 
> CONFIG_HW_RANDOM=y seems to come along for the ride with the
> `./scripts/config -e modules && make olddefconfig && make
> savedefconfig`. The measurements above include it, I haven't
> investigated why it gets enabled or what effect disabling it might have
> on the numbers.
> 
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>  arch/arm/configs/aspeed_g5_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/aspeed_g5_defconfig b/arch/arm/configs/aspeed_g5_defconfig
> index e124b4ddd442..e30f27a413f4 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -46,6 +46,7 @@ CONFIG_NEON=y
>  CONFIG_KERNEL_MODE_NEON=y
>  CONFIG_FIRMWARE_MEMMAP=y
>  CONFIG_JUMP_LABEL=y
> +CONFIG_MODULES=y
>  # CONFIG_BLK_DEV_BSG is not set
>  # CONFIG_BLK_DEBUG_FS is not set
>  # CONFIG_MQ_IOSCHED_DEADLINE is not set
> @@ -152,6 +153,7 @@ CONFIG_SERIAL_8250_DW=y
>  CONFIG_SERIAL_OF_PLATFORM=y
>  CONFIG_ASPEED_KCS_IPMI_BMC=y
>  CONFIG_ASPEED_BT_IPMI_BMC=y
> +CONFIG_HW_RANDOM=y
>  CONFIG_HW_RANDOM_TIMERIOMEM=y
>  # CONFIG_I2C_COMPAT is not set
>  CONFIG_I2C_CHARDEV=y
> -- 
> 2.25.1
> 

We're already using modules on the facebook/openbmc kernels and it
hasn't seemed to cause any issues.  Is there any argument why we
shouldn't begin moving some of the drivers to be modules?  Any easy
change would be to make all the hwmon content as modules and load them
based on the device tree.

I think there is a DISTRO_FEATURE we should enable for userspace support
of modules.  Let me know if you want me to investigate that.

Reviewed-by: Patrick Williams <patrick@stwcx.xyz>

-- 
Patrick Williams