modules, firmware, kernel size
jwboyer at gmail.com
Thu Oct 18 15:10:11 UTC 2012
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
> 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
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.
More information about the devel