All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Quentin Schulz" <quentin.schulz@streamunlimited.com>
To: Ryan Harkin <ryan.harkin@linaro.org>
Cc: yocto@yoctoproject.org, Nicolas Dechesne <nicolas.dechesne@linaro.org>
Subject: Re: [yocto] Building and selecting multiple kernel versions
Date: Tue, 4 Feb 2020 09:51:54 +0100	[thread overview]
Message-ID: <20200204085153.6wsex564rtrknfuq@qschulz> (raw)
In-Reply-To: <CAD0U-h+q4k-EywV8XEfZ2nsoHoRQaNyRy77E2kRLuos8dAmNTA@mail.gmail.com>

Hi Ryan,

On Mon, Feb 03, 2020 at 05:34:23PM +0000, Ryan Harkin wrote:
> Hello all,
> 
> I'm looking for advice on how to support multiple kernel versions in my
> distro with minimal changes, and minimal disruption to my users.
> 
> Some background:
> 
> I have a legacy Sumo based distro with an image config, and a machine
> config, with the machine using a 4.9 kernel. Last year, I upgraded
> everything to Warrior, and moved to a 4.19 kernel.
> 
> Some of my users who are migrating from Sumo, wish to keep their 4.9
> kernel. So I'm trying to work out how to handle this in the simplest way.
> 
> I know that I can add a 4.9 recipes to my Warrior branches, set
> PREFERRED_VERSION in my distro.conf. But I don't want to change the default
> preferred version globally. And I don't really want users to update the
> distro.conf. Ideally, they should be able to take what I give them and
> "just" build it to get a 4.9 or 4.19 variant.
> 

You can make two machine configuration files. One with
PREFERRED_VERSION_virtual/kernel = "4.9%" and the other with 4.19.

They pick the correct machine when building, they should expect the
correct kernel in output. Only applies to images built for this machine
so I guess that's what you're looking for?

> Ideally, I don't want to *have* to build both kernels and then create two
> images. I expect that will cause confusion and lead to people flashing the
> wrong images. So I'd prefer it to be either/or. Of course, I have to test
> all of this, so I want to be able to build both variants in CI, which makes
> editing distro.conf even more  unattractive.
> 

Same image (POV of bitbake <image>) but different machines, does that
match your requirements?

FWIW, you can pass MACHINE= to the command line just before bitbake
<image> making it rather obvious which machine they pick.

Quentin

  reply	other threads:[~2020-02-04  8:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 17:34 Building and selecting multiple kernel versions Ryan Harkin
2020-02-04  8:51 ` Quentin Schulz [this message]
2020-02-04 16:00   ` [yocto] " Ryan Harkin
2020-02-04 16:15     ` Quentin Schulz
2020-02-04 16:32       ` Ryan Harkin
     [not found]         ` <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.fbe4d9d0-dcb7-4337-a01d-e3e508e8a194@emailsignatures365.codetwo.com>
2020-02-04 16:39         ` Quentin Schulz
     [not found]           ` <43191ed2-9653-a4f8-4b2a-1bc655e80953@topicproducts.com>
2020-02-05 17:08             ` Ryan Harkin

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=20200204085153.6wsex564rtrknfuq@qschulz \
    --to=quentin.schulz@streamunlimited.com \
    --cc=nicolas.dechesne@linaro.org \
    --cc=ryan.harkin@linaro.org \
    --cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.