[Openembedded-architecture] Heterogeneous System Proposal

Mark Hatle mark.hatle at kernel.crashing.org
Mon Dec 2 23:56:55 UTC 2019



On 12/2/19 5:47 PM, Richard Purdie wrote:
> On Mon, 2019-12-02 at 15:27 -0800, Alejandro Enedino Hernandez
> Samaniego wrote:
>> So I have tried something similar to this, and while it does work,
>> due to some parsing issue (I still have not figured out exactly what)
>> the multiconfig dependencies between multiconfigs are not being taken
>> into account, which defeats the whole purpose.
> 
> It likely makes sense to understand why its breaking since wouldn't
> those issues affect this regardless of which direction things go in?
> 
>> While I understand that introducing a new variable might create some
>> confusion, at the same time I do believe that it would be
>> better if we do it that way, and in some way separate workflows when
>> we are building a "full" heterogeneous system vs a single
>> architecture system, the difference lies in the fact that we dont set
>> what the "master" or core MACHINE is, they are all equal.
>>
>> I have been working on the implementation of this proposal and here
>> is what I currently have for which of course I am open to change.
>>
>> Like I said, I had issues with defining a placeholder machine for the
>> multiconfig dependencies, so I did go with defining
>>
>> SYSTEM = "dummy-system"
>>
>> on local.conf (also not a huge fan of the name since to me its a bit
>> too generic,but as RP said, the name is probably the least of our
>> problems)
>>
>> then
>> include conf/system/${SYSTEM}.conf
>>
>> and I have the following set up on a layer:
>>
>> meta-heterogeneous
>>   conf/layer.conf
>>   conf/system/dummy-system.conf
>>   conf/multiconfig/dummy-arm64.conf
>>   conf/multiconfig/dummy-x86-64.conf
>>   recipes-heterogeneous/heterogeneous-example_1.0.bb
>>
>> Explanation:
>> layer.conf  - normal layer.conf, nothing out of the ordinary
>> dummy-system.conf - Defines BBMULTICONFIG as dummy-arm64 and dummy-
>> x86-64, AND defines the multiconfig dependencies between them
>> dummy-*64.conf - Define each of the multiconfigs, in them there are
>> only 3 variables, DISTRO, MACHINE (qemuarm64 and qemux86-64
>> respectively), and TMPDIR which is simpy defined as tmp-${MACHINE}
>> heterogeneous-example_1.0.bb : This was a placeholder recipe, since
>> to my knowledge bitbake required a target, and it simply contained a
>> line that set up a multiconfig dependency that would allow:
>>
>> $ bitbake heterogeneous-example
> 
> I'm going to try and make a concise reply to both you and Mark.
> 
> What worries me is that in this "dummy-system" context there is only
> one valid recipe which is the heterogeneous-example, everything else is
> meaningless.

My assumption was that, like a baremetal system, recipes would be limited to a
small number of things -- primarily different image recipes.  But this is out of
convention rather then actually modifying things to say 'only images can be used'.

> If we go this route we'll start having to add special corner casing for
> "nomachine" and "notune" and everywhere, then special case those values
> since there is code they will need to pass through. I don't think these
> concepts make sense to the majority of users and I think the damage
> we'd do to the metadata trying to retrofit them will be significant and
> not in the interests of the project.

(I choose the names nomachine and notune to match the existing nodistro option.
 Provide reasonable defaults that do the 'right thing' within that context.)

I was expecting the opposite here.  We wouldn't modify any existing code (I
think), so hashes, metadata etc wouldn't need to be modified.  Since nomachine
would presumably load notune.. Then the notune could define a blank tune that
doesn't "do antyhing".

The only place we may need some code is in an anon python chunk that if notune
is defined and the recipe isn't noarch/all.. it would raise the skipRecipe
exception with an appropriate message.

> Looking at things a different way, the proposal makes little difference
> to adding a new machine above called "dummy-system" which sets up the
> multiconfigs, it just gives it a different name, SYSTEM instead of
> MACHINE. I think you can achieve much of (all?) the same things with a
> naming convention rather than needing a new namespace. If multiconfig
> has bugs with that, we should fix them?

Agreed.  SYSTEM, MACHINE, MACHINE w/ a convention.. it's all fine, as long as we
have a standard way to refer to the item and define it.

--Mark

> Cheers,
> 
> Richard
> 
> 
> 


More information about the Openembedded-architecture mailing list