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

Peter Robinson pbrobinson at
Wed Oct 17 17:45:42 UTC 2012

On Wed, Oct 17, 2012 at 6:34 PM, drago01 <drago01 at> wrote:
> On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones <rjones at> wrote:
>> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
>>> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
>>> <mattdm at> wrote:
>>> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
>>> >> > Basically: it's hard,
>>> >> it is a mess.
>>> >> > but the only way we're going to get to a
>>> >> > reasonably-small minimal image,
>>> >> not true.
>>> >
>>> > 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;
>> [I'll treat these two the same, because they amount to the  same thing]
> No the one means we ship a kernel-foo (like kernel-minimal or whatever
> we call it) and the other is you build your own kernel.
>> It's a considerable amount of work for everyone if people building
>> minimal images have to use a different kernel.
> If it is all about using kernel-minimal (or whatever it is called)
> instead of kernel there is no extra work for the ones that build
> minimal images at all.
>> By using the same kernel as everyone else, it means that bug reports
>> against the normal kernel package are relevant, and it means that the
>> regular kernel gets more testing.
> They can be built from the same srpm (same version, same patches
> applied just some modules stripped).
>> Also it's a lot of work to compile another kernel, when we've already
>> got a team of (apparently 3) people doing this.
> I'd argue it is less work then building a subpackage for every kernel module.
>>> use a compressed filesystem,
>> Every minimal image I've ever seen has been compressed to the max.
> The image itself might be the installed system isn't ... which is the
> think I was talking about (i.e this would allow you to save disk space
> after installation).
> The smaller image would just save bandwidth for the initial download
> and/or space on mirrors.
>>> don't use a kernel at all and some
>>> container based approach instead of full virt for your cloud instances
>> Unfortunately containers don't work for every application out there.
>> Obviously *if* you can use a container, then you should, and you
>> probably are already.
> That might be true but I can't think of such applications right now.
> Couldn't the applications you have in mind be modified / fixed to work
> in such an environment?
>>> 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).
>> It's partly disk space, it's more often the time taken to copy these
>> images over the network (eg. when users download minimal images, or
>> when they are PXE-booted).
> In that case you should place the image on your internal network. I
> doubt anyone uses a cloud infrastructure where you download the images
> over the internet using a 56k modem.
>>> So there are lots of other ways to achieve what you want without
>>> splitting the kernel into hundreds of sub packages.
>> I don't think we're talking "hundreds" of sub packages.  Most people
>> seem to be discussing a split into between 2 and 5 packages.
> People where talking about splitting each module ("driver") into its
> own package. This are far more then 5.

Not necessarily, I was the person wanting it split down and only to
groups of packages like "usb" for usb devices, "arm" for arm only
firmware, "storage" for enterprise storage, "wifi" etc.


More information about the devel mailing list