Bug#772983: kirkwood kernel image is too big
On Fri, 2014-12-12 at 20:59 +0000, Ben Hutchings wrote:
> > I had originally planned to switch QNAP over for 3.16 but it wasn't
> > quite ready upstream (I've forgotten why). The board files went away in
> > 3.17 so in experimental (v3.18) appending is necessary. Once I've worked
> > out some kinks with kirkwood in v3.18 I was planning to upload a
> > corresponding flash-kernel which does appending for those platforms.
>
> In case you hadn't noticed, I've changed the size check in trunk so it
> can optionally include the size of the largest DTB. That is somewhat
> pessimistic in that the largest DTB probably won't be used in
> conjunction with the smallest partition.
I had seen, I think it's a good idea despite the short comings. The size
difference between the smallest and largest DTB is only 14K so it's
pretty close either way.
To be more accurate we'd need to store the name of the dtb corresponding
to the smallest partition in the kernel source, making the (reasonable)
assumption that the second smallest partition is at least 14K larger
than the smallest. I don't know that it's worth it though.
> I enabled this for both
> kirkwood and orion5x, though now I think I should not have done so for
> orion5x.
I think you were right to do so even for orion5x (in trunk at least).
Right now there are only a small numbers of dtbs built on orion5x, and
they are all <8K. As upstream transitions from board files to dtb that
number (and the sizes) will grow, but it's not skewing our results too
much to check now.
At some point upstream will remove the board file support for orion5x,
so I think it is fine to start checking the sizes now even while we are
still on board files, so we are prewarned.
> [...]
> > > 2094680 < 2097080
> > > 2094680 + 10394 = 2105074 > 2097080
> > >
> > > The orion5x machine with the smallest known kernel partition is D-Link
> > > DNS-323, with 1572792 bytes space. We currently have less than 1 KB
> > > to spare here. Thankfully this machine is still supported by board
> > > code and doesn't need a DTB. But if any of the other orion5x machines
> > > we intend to support have a similarly small kernel partition and
> > > require a DTB they will not work with this version.
> >
> > I don't know much about orion5x, but the flash-kernel db tells me that
> > we don't currently append a dtb on any platform there.
> >
> > 1k is rather tight though, even if appending isn't needed. A security
> > update adding 1k of binary size wouldn't be totally out of the question
> > and it would be unfortunate to have to start disabling features in a
> > security update.
>
> Yes, you're right. For comparison, this is what's happened over the
> course of wheezy stable updates:
>
> 3.2.41-2 3.2.63-2 limit growth% growth limit%
> iop32x: 1427968 1434632 1441784 0.47 0.97
> ixp4xx: 1424696 1428920 1441760 0.30 1.20
> kirkwood: 1606512 1613040 2097080 0.41 30.54
> orion5x: 1475936 1483632 1572792 0.52 6.56
>
> They've grown by up to about 0.5% over the course of 20 months of a ~36
> month support period. That implies we want to allow for about 1% growth
> from the size in the .0 release. Thankfully they did all start with
> this much space.
>
> Currently in sid we have:
>
> 3.16.7-ckt2-1 limit growth limit%
> ixp4xx: 1429712 1441760 0.84%
> kirkwood: 2094488 2097080 0.12%
> orion5x: 1568248 1572792 0.29%
>
> I misread earlier - kirkwood is about 2.5 KB below the limit, not < 1.
> Anyway, both kirkwood and orion5x have much less than 1% of growth room
> and ixp4xx has slightly less. I think that some of the config changes I
> made in trunk should be applied to jessie/sid as well.
I agree. I suppose you have some candidates in mind?
Ian.
Reply to: