On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus <dzickus(a)redhat.com> wrote:
On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red"
For example, lets start with 100MB package requirement for the kernel (and
say 2 GB for userspace). This way the kernel team can implement
reasonable changes and monitor proper usage (because things grow over
If later on you realize 100 MB is not competitive enough, come back and
chop it down to say 50 MB and let the kernel team figure it out.
But please do not come in here with a 'every MB counts' approach. It is
not very sustainable for future growth nor really easy to implement from
an engineering approach.
Is that acceptable? The kernel team can start with a hard limit of 100MB
package requirement (or something reasonably less)? Let's work off budget
This is a fair point. To be honest, I've ignored the "every MB
counts" aspect entirely for now. I've instead been focusing on
required functionality, because that's likely going to be the main
driver of what the resulting size will be.
FWIW, the existing kernel package installed today (a debug kernel
even) is ~142 MB. 123MB of that is the /lib/modules content. ~6MB of
that is vmlinuz. The remaining 13MB is the initramfs, which is
actually something that composes on the system during install and not
something we can shrink from a packaging standpoint.