* Olof Johansson [off-list ref] [130802 22:37]:

On Fri, Aug 2, 2013 at 2:31 PM, Matt Sealey [off-list ref] wrote:

quoted

On Fri, Aug 2, 2013 at 3:13 AM, Tony Lindgren [off-list ref] wrote:

quoted

* Mel Gorman [off-list ref] [130731 08:28]:

quoted

On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote:

quoted

Hi all,

Probably the biggest kernel data bloat issue is in the ARM land, but
it also seems that it's becoming a Linux generic issue too, so I
guess it could be discussed in either context.

Would scripts/bloat-o-meter highlight where the growth problems are?

Well to some extent yes, the board/SoC/driver specific options are
often behind Kconfig options. So if you want to limit the set of
supported SoCs and drivers for the kernel you can optimize it out.

The bloat-o-meter won't help for things like checking that a device
tree binding really describes the hardware, and is not just pointing
to a table of defined registers in the device driver.

Specifically naming and shaming, like arch/arm/mach-imx/clk-*.c kind

[...]

TL;DR. Some friendly advice is to reduce the verbosity of your emails.
I lost patience a couple of paragraphs in.


I think we could come a long way on this if we could sort out probe
and init order enough that we could modularize some of this data (and
init code). I.e. if you could load some of these tables and drivers as
modules a lot of the bloat would no longer be an issue.

The problem, of course, is that things like clock, pinmux, etc tables
(and drivers) tend to be needed very early during boot and thus can
definitely not wait to the point where we usually run ramdisk
contents.

I think there's no need for that any longer. We've pretty much sorted
out all the issues so not much is needed early on.

Sure some clocks might be needed for the SoC specific clockevent.
But if those can be defined in the .dts files only those need to
be initialized early on.

For the pinmux, bootloader already must set up pins for SDRAM so
not much should be needed early on. But if some pins are needed, those
should be defined in the .dts files and the rest can be initialized
later on based on .dts, loadable modules, or /lib/firmware.
 

We could mandate that whatever drivers are needed on top also be
modules, which would take care of some of the dependency chain, but we
don't have a great way today to describe the needed probe/load order
of said modules. So it'd still need some new and additional
functionality to work well.

Hmm I think we're just missing a concept of initializing the SoC
specific things in stages as most of it can be done at module init
time as long as the needed pieces can be initialized early.
 

Pushing everything out into modules will also add some complexity for
embedded platforms who rather avoid ramdisks, and it will likely add
boot time which matters a lot to some users. On the other hand, it's
less likely to matter to the users who at the same time care about the
bloat of a multiplatform kernel, i.e. you tend to ether optimize for
boot time on particular well-defined hardware, or you care more about
having something that boots on most hardware but possibly with some
overhead in boot performance.

The Linux generic frameworks should support initializing things
in multiple stages. Some of them do, but not all of them. Then
depending on the use case, SoC specific things can be initialized
with a suitable combination of .dts entries, loadable modules and
data from /lib/firmware.

Regards,

Tony