Re: [RFC PATCH 1/1] kernel: add kernel-image-fitimage-initramfs

Richard Purdie
2022-04-13T15:48:07Z

On Wed, 2022-04-13 at 09:18 +0200, Claudius Heine wrote:
> Hi,
>
> On 2022-03-30 11:15, Claudius Heine wrote:
> > When creating an initramfs bundled into a kernel fitimage, the resulting
> > fitimage will only be placed into the deploy directory and not packaged
> > by the kernel recipe/class.
> >
> > Changing the kernel recipe/class to produce a package with the fitimage
> > containing the initramfs is not possible, because build dependencies
> > require the kernel packages to be already build before the initramfs can
> > be created.
> >
> > The kernel-image-fitimage-initramfs recipe solves this dependency cycle
> > by packaging the fitimage with the embedded initramfs from the deploy
> > directory and replaces the `kernel-image` and `kernel-image-fitimage`
> > packages from the kernel recipe/class.
>
> This patch was on master-next for a short while, any feedback on it?
>
> In the cover letter I stated the only downside of this solution is, that
> in case of package based updating, it would require manually changing
> the version of this recipe.
>
> Is this an acceptable downside, or is there a good way to fix this?

There were a few things which concern me. It is late in the release cycle for
this to make it into kirkstone so I was deferring it until 4.1 and the next
development cycle.

I was worried that it doesn't have a maintainers entry. I was also worried that
it doesn't have any tests and doesn't get used at all on the autobuilder. There
doesn't seem to have been much other feedback/review on the mailing list either.
There also isn't any documentation. This makes it likely to become a piece of
untested and potentially dead code going forward.

People are fixing up bits of the fitimage and initramfs code adhoc with just
enough changes to sovle their use case. We really need docs and tests and
ideally a clear plan on how this all fits together.

I suspect that the downside you mention, the fact that the kernel is removed
from package management will also catch people out. It is different to our
normal behaviour and I don't know how we highlight to users that this issue is
present.

I'm also worried that we don't have enough people looking at rewiew and that
there are probably issues here we need to discuss but we simply don't have the
right people with time to look at and think about it. I'm not the subject matter
expert here :(.

I wish I had something I could say as to how to make it acceptable to merge
(definitely needs tests) but I really don't know this area well enough and I
haven't had the time to think enough about it. It hovered in -next for a while
as I was trying my best to do so but with the release breaking I needed to clear
out -next for my own sanity and this ended in my defer pile. Even writing the
email explaining why takes 10 minutes.

Cheers,

Richard