From: Kevin Hilman <khilman@deeprootsystems.com>
To: Olof Johansson <olof@lixom.net>
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP2/3: update default defconfig, towards smaller kernel
Date: Mon, 01 Feb 2010 12:20:30 -0800 [thread overview]
Message-ID: <87k4uwg12p.fsf@deeprootsystems.com> (raw)
In-Reply-To: <20100201194926.GA5819@lixom.net> (Olof Johansson's message of "Mon\, 1 Feb 2010 13\:49\:26 -0600")
Olof Johansson <olof@lixom.net> writes:
> On Fri, Jan 29, 2010 at 04:26:56PM -0800, Kevin Hilman wrote:
>> Update omap3_defconfig to work towards a minimal kernel by building
>> most things as modules. Some drivers that cannot currently be built
>> as modules and need to be fixed:
>
> Why? I introduced the omap3_defconfig with the intent of making it as
> inclusive as possible, to catch build errors and build a common binary
> for many platforms.
That's my goal too, as I regularly test the same kernel (in my case
PM-enabled) on multiple OMAP3 boards. The only additional goal I have
is to the kernel as small as possible and build most things as
modules.
I don't change what gets included in the build, I only moved some
things from being built in to be built as modules. Doing 'make
[uz]Image modules' will still catch all the build errors and build a
common binary.
> It's the only OMAP defconfig that Stephen Rothwell
> builds as part of a linux-next cycle, and it will as such need to catch
> build errors when others break ARM/OMAP.
If linux-next is not also building modules for OMAP, we need to
request that it does. It does so for other platforms.
>
>> - MMC: platform code uses MMC core regulator functions directly
>> - ASoC: drivers call omap_ctrl_[read|write] directly
>>
>> In addition some additional changes:
>>
>> - use new SLUB allocator instead of SLAB (increased debugability)
>> - compile with PREEMPT enabled by default
>> - disable OABI_COMPAT. We should not pretend to support this IMHO
>> - disable CPUfreq: not yet supported in mainline
>> - disable PM_DEBUG_VERBOSE
>> - enable fb/DSS2 as modules
>> - disable Kprobes
>>
>> zImage size comparison
>> before: 3160272
>> after: 2610108
>>
>> Some ideas for reducing this further:
>> - fix MMC and ASoC, then build those as modules
>> - disable all the kernel debug features
>> - convert MTD and all flash fs to modules
>>
>> Then, we should have platform specific initramfs configs so rootfs
>> from flash, MMC, etc. could be done using modules in initramfs.
>
> I'm all for allowing an "allmodconfig" kernel to be booted, and it's good
> to clear up some of these dependencies. But I'd prefer if it wasn't done
> under omap3_defconfig. :)
Why not?
Building a monolithic kernel for multiple boards leads to lots of
wasted memory and slower boot time.
At a minimum, I'd at least like to get to "build everything except
possible root filesystems as modules" kernel.
Kevin
next prev parent reply other threads:[~2010-02-01 20:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 0:26 [PATCH] OMAP2/3: update default defconfig, towards smaller kernel Kevin Hilman
2010-01-30 2:01 ` Nishanth Menon
2010-01-30 10:25 ` Koen Kooi
2010-02-01 17:32 ` Kevin Hilman
2010-02-01 16:09 ` Madhusudhan
2010-02-02 17:44 ` Kevin Hilman
2010-02-01 19:49 ` Olof Johansson
2010-02-01 20:20 ` Kevin Hilman [this message]
2010-02-01 20:37 ` Olof Johansson
2010-02-01 20:52 ` Kevin Hilman
2010-02-01 23:03 ` Mike Turquette
2010-02-01 21:39 ` Madhusudhan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k4uwg12p.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=olof@lixom.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.