modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)

Seth Vidal skvidal at
Wed Oct 17 16:54:48 UTC 2012

On Wed, 17 Oct 2012, Dave Jones wrote:

> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> > > Given that the kernel is currently a full quarter of the current image, I
> > > think it has to be.
> >
> > No you could also use a different kernel image; build your own kernel;
> > use a compressed filesystem, don't use a kernel at all and some
> > container based approach instead of full virt for your cloud instances
> > (you could even base them on a btrfs subvolume and save more space
> > that way).
> >
> > Outside of the cloud use case the disk space added by modules and
> > firmware does not matter a bit (so I am ignoring this cases).
> >
> > So there are lots of other ways to achieve what you want without
> > splitting the kernel into hundreds of sub packages.  So while it is a
> > way it is not "the only way".
> As reluctant as I am to introduce new kernel packages, an ultra-minimal
> kernel package for use in cloud environments may make more sense than
> splitting up the one-size-fits-all packages into hundreds of sub-packages.
> But even this option is a lot of work, and isn't a panacea.
> With virtualised environments supporting pci/usb passthrough, where do you
> draw the line on what hardware to support in a hypothetical kernel-cloud package ?

You don't. More importantly I think the goal of shrinking the minimal 
install is a bad one. We're chasing a size that is better suited by custom 
spins or specific cloud installs. It should not be a goal of a 
distribution provider to crreate something custom tailored for a specific 


More information about the devel mailing list