modules, firmware, kernel size

[Josh Boyer]

On Thu, Oct 18, 2012 at 11:02 AM, Benny Amorsen <benny+usenet at amorsen.dk> wrote:
> Josh Boyer <jwboyer at gmail.com> writes:
>
>> Of course we would.  The entire point is to reduce the size, and the
>> only way to reduce the size is to build it with different config
>> options.
>
> Just splitting off most modules would do the job I would think... Of
> course you can go smaller if you change config options, but that is a
> lot of work.
>
> Maintaining a list of core modules does not sound like an unbearable
> task. (Easy for me to say, of course). Then everything else under
> /lib/modules can go into a separate RPM.

Your definition of core modules is going to differ from mine, and the
next persons, and the next.

> # rpm -ql kernel-3.6.1|grep ^/lib|xargs du -c
> 31488   total
>
> # du  -s /lib/modules/3.6.1-1.fc17.x86_64/
> 100324  /lib/modules/3.6.1-1.fc17.x86_64/
>
> Making sure that the right systems get the extra module RPM is left as
> an exercise for the reader.

It's not simple.  It's not easy.  It buys you very very little and it
leaves the maintainers having to continuously guess which package a
module goes into.  Then there's the requests to move them from one to
the other.

I'm _very_ against splitting the modules up more than they already are.
The modules-extra subpackage has been somewhat a pain already, and those
are the modules that are very rarely used.  Extending it to common ones
leaves me with a headache just thinking about it.

josh