Re: [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig

From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Ross Burton <ross.burton@arm.com>, poky@lists.yoctoproject.org
Cc: openembedded-core@lists.openembedded.org,
	 openembedded-architecture@lists.openembedded.org
Subject: Re: [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig
Date: Wed, 21 Feb 2024 11:21:39 +0000	[thread overview]
Message-ID: <ee6a686362c533dc70c442b64c96ca23b8bde45c.camel@linuxfoundation.org> (raw)
In-Reply-To: <20240221105723.1501833-1-ross.burton@arm.com>

On Wed, 2024-02-21 at 10:57 +0000, Ross Burton wrote:
> From: Ross Burton <ross.burton@arm.com>
> 
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly forward-leaning as there's
> not a _lot_ of SystemReady hardware in the wild, but most modern boards
> are and the number will only grow.  Also, this is the only way to have a
> 'generic' machine as without standardised bootloaders and firmware it
> would be impossible.
> 
> The base machine configuration isn't that exciting: it's a fully featured
> machine that supports most things, booting via UEFI and an initramfs.
> 
> However, the kernel is more interesting.  This RFC uses the upstream defconfig
> because unlike some other platforms, the arm64 defconfig is actively
> maintained with the goal of being a 'boots on most hardware' configuration.
> My argument is: why would we duplicate that effort?

Can you point at the policy/process which decides how a config option
makes it in there?

> The "linux-yocto way" is configuration fragments and after a week of
> hair-pulling I do actually have fragments that boot on a BeaglePlay, but
> to say this was a tiresome and frustrating exercise would be understating it.
> 
> So, a request for comments: is it acceptable to use the upstream defconfig in
> a reference BSP?  Personally I'm torn: the Yocto way is fragments not monolithic
> configs, but repeating the effort to fragmentise the configuration and then
> also have it sufficiently modular that it can be used in pieces - instead of
> just being a large file split up into smaller files - is a lot of effort for
> what might end up being minimal gain.  My fear is we end up with a fragmented
> configuration that can't be easily modified without breaking some platforms,
> and badly copies what the defconfig already does.

Let me play devils advocate.

I do understand it is a pain, equally, once you do have it working, it
is something you rarely have to touch again for a given board.

In the context of linux-yocto, I suspect we'd end up with a few board
specific lists of config options (fragments) that board *really* needs.
genericarm64 would end up as the sum of all those configs, plus any
other bits which you really want in a generic machine, presumably the
genericx86 machines have an idea of that.

The advantage here is that you give the users three options:

a) the kitchen sink upstream "systemready" defconfig
b) the genericarm64 machine defconfig which works most places and 
   is 'guaranteed' on our target test platforms
c) a machine targeted defconfig with only what a board needs

Developers/users end up in different places at different points in
there lifecycles. 

For in depth development, you might like to be able to cut the kernel
down so you'd not rebuilding tons of stuff you don't need/use/care
about each time, nor transferring it to a device during updates.

For a specific product release, you again might want to trim it down to
what it needs.

If you're shipping demo software, a full systemready image would be
much more appropriate.

I think it comes down to whether the fragments are usable and testable.
We have a list of targets we want this new machine to run on so lets
start with those, define genericarm64 as that set of fragments combined
plus the generic pieces linux-yocto adds, then go from there. If you
add a new machine to the test matrix, we add a new fragment. If someone
wants to add new config, they need to show a machine using it.

Cheers,

Richard