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

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]

Hi,

On Fri, Dec 26, 2014 at 08:38:10PM +0100, Javier Martinez Canillas wrote:
> > I wonder the same thing, but look at multi_v7_defconfig today. Almost
> > everything is built-in, which makes the kernel image enormous (5.5MiB).
> >
> >> 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?
> >
> > if people accept switching some of those as modules, sure. I don't mind
> > that at all. I'll still continue to maintain my out-of-tree defconfigs
> > for my boards anyway. It's also very good to have a generic defconfig
> > which will just work with everything I have.
> >
> >> 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].
> >
> > lol, that's the reason why I don't use multi_v7_defconfig.
> >
> 
> Agreed, on its current form I wonder what's the use case for
> multi_v7_defconfig. I guess most options will slowly be changed to be
> built as a module though to be similar to what distros do.

that's the idea with omap2plus_defconfig, at least. Last I talked with
Tony, the idea was "let's have a defconfig which distros can just use
and almost everything is built as a module".

> >> 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 never claimed that people should not use it as a *base*, rather it
> > should not be used to build a product's kernel/modules. Imagine you
> > shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
> > MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
> > built-in, etc. It's a waste of space and just bloats that product's
> > zImage.
> >
> 
> Got it, thanks for the clarification. I agree that omap2plus_defconfig
> is very bloated to be used for products as-is. I also have custom
> defconfig to test the OMAP boards I maintain which is basically
> omap2plus_defconfig + a merged config fragment (using merge_config.sh)
> that disables and enables needed options.

right, I used to that too. But right now I just have a set of
config-$board which I maintain locally. Slowly moving to
omap2plus_defconfig only as I move all my boards to NFS root.

> >> 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.
> >
> > OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
> > final saying about it, right ?
> >
> 
> Sorry, I didn't mean that Tony doesn't have the last word for omap
> defconfig. My point was that it should be nice to get a consensus
> about this and specially document it to make life easier for everyone.

definitely, we need at least some documentation. No questions there.

> People posting defconfig changes will know what the rule is and we can
> avoid having these kind of discussions which I have had many times in
> the past when posting defconfig changes and I'm sure I will have more
> in the future again.

right.

> But I don't really mind tbh, I will keep maintaining my custom
> defconfigs anyways and post wnen I think that enabling a config option
> in a mainline defconfig makes sense and will do as a module or
> built-in depending of what the SoC maintainer tells me to use.

yeah, that's the downside, really. One maintainer prefers small zImage
with several modules (which I very much like the idea) while another
prefers giant zImage with virtually no modules :-)

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]