public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Claudius Heine <ch@denx.de>, openembedded-core@lists.openembedded.org
Cc: Alexander Kanavin <alex.kanavin@gmail.com>
Subject: Re: [RFC PATCH 1/1] kernel: add kernel-image-fitimage-initramfs
Date: Wed, 13 Apr 2022 08:35:36 +0100	[thread overview]
Message-ID: <af4b0806c4668d272b38dd6def483451f45c8a9e.camel@linuxfoundation.org> (raw)
In-Reply-To: <ec096923-51a9-5407-9836-689c3ac2d4d2@denx.de>

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




  reply	other threads:[~2022-04-13 15:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30  9:15 [RFC PATCH 0/1] Packaging a fitimage with initramfs Claudius Heine
2022-03-30  9:15 ` [RFC PATCH 1/1] kernel: add kernel-image-fitimage-initramfs Claudius Heine
2022-04-13  7:18   ` Claudius Heine
2022-04-13  7:35     ` Richard Purdie [this message]
2022-04-13  7:50       ` Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=af4b0806c4668d272b38dd6def483451f45c8a9e.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alex.kanavin@gmail.com \
    --cc=ch@denx.de \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox