[PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Javier Martinez Canillas]

Hello all,

On Fri, Dec 26, 2014 at 12:56 PM, Igor Grinberg <grinberg at compulab.co.il> wrote:
>>>>> Tony, your call.
>>>>
>>>> I think we should move omap2plus_defconfig to be mostly modular and
>>>> usable for distros as a base. Most distros prefer to build almost
>>>> everything as loadable modules. And my preference is that we should
>>>> only keep the minimum rootfs for devices and serial support as
>>>> built-in and rely on initramfs for most drivers. And slowly move
>>>> also the remaining built-in drivers to be loadable modules.
>>>>
>>>> The reasons for having drivers as loadable modules are many. It
>>>> allows distros to use the same kernel for all the devices without
>>>> bloating the kernel. It makes developing drivers easier as just the
>>>> module needs to be reloaded. And loadable modules protect us from
>>>> cross-framework spaghetti calls in the kernel as the interfaces are
>>>> clearly defined.
>>>>

I do agree with Tony and Felipe that we should try to build as much
stuff as possible as a module instead of built-in to match what
distros do and what has been done for x86 for years.

However, if that's the case I wonder what's the point of having both
an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense
to get rid of the SoC specific configs then and just use the single
ARMv7 defconfig for all SoCs with most of the options enabled as a
module?

FYI, some time ago I posted a patch to enable SBS-compliant batteries
support as a module for Exynos defconfig and was told to re-spin the
patch and enabling it as built-in instead since the most popular use
case for exynos_defconfig was development and people usually just copy
the kernel binary and not the modules [0].

So it seems that each ARM SoC community has a different opinion about
how things should be configured and do it differently.

>>
>> bullshit, you would never ship a product with omap2plus_defconfig. You'd
>> build your own at which point you would switch SATA to built-in.
>

There are different opinions but let please try to keep the discussion
constructive and use a polite tone.

>>>
>>> Right now, we tell our customers that they can use mainline with
>>> omap2plus_defconfig.
>>
>> that's the worst thing you can do.
>

I'm confused, Felipe said that customers should not base their config
from omap2plus_defconfig but AFAUI Tony's argument is exactly the
opposite, that everything should be configured as a module so distros
can use omap2plus_defconfig as a base. So, is or is not expected that
people will use omap2plus_defconfig as a base for their own config?

I think the problem is that there isn't an agreement about what is the
purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
defconfigs (or at least is not well documented since I could not find
it). So, IMHO this concern should be raised to the ARM SoC maintainers
and there should be an agreement in the ARM community as a whole about
how things should be configured on each defconfig, and all SoCs should
follow the agreed rule.

Otherwise it seems that the motivation for each kconfig symbol enabled
is just to make the workflow of the developer posting the patches
easier and wins whoever shouts louder.

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg353808.html