Okay, let us use v6 to track the patch.

Thanks,
________________________________
From: Bruce Ashfield <[email protected]>
Sent: Friday, June 9, 2023 11:25
To: Yu, Mingli <[email protected]>
Cc: Richard Purdie <[email protected]>; 
[email protected] 
<[email protected]>
Subject: Re: [OE-core] [PATCH v5] qemu: Split the qemu package

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.


On Thu, Jun 8, 2023 at 10:01 PM Yu, Mingli 
<[email protected]<mailto:[email protected]>> wrote:
Hi Bruce,

I didn't reply the v1 patch directly and just include the comments and concerns 
when generate v2,v3,v4,v5 patch.

I'm sorry the overrides for qemu split in meta-vir as 
https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc
 doesn't work if we make the qemu split 
change.<https://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$>

<https://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$>
Is it okay for you to install the qemu arch rpms you need or qemu-all(if you 
want all qemu binary) after the qemu split 
change?<https://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$>

It actually isn't that. I want a different split of the packages.

But I see your v6 is using the function variable, so I'll be able to remove it 
from processing and restore my existing package splits.

Bruce



<https://urldefense.com/v3/__https://git.yoctoproject.org/meta-virtualization/tree/recipes-devtools/qemu/qemu-package-split.inc__;!!AjveYdw8EvQ!byty5y3CfmOOKUh8G_uYgU2QxFCl4KCFb-yjmzYuSrjQJ4NXaglf6vZ6IWtmyrHhPs4okTIp4TpusD8e4h8-YLvToqA$>

Thanks,
________________________________
From: Bruce Ashfield <[email protected]<mailto:[email protected]>>
Sent: Friday, June 9, 2023 00:16
To: Richard Purdie 
<[email protected]<mailto:[email protected]>>
Cc: Yu, Mingli <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
 
<[email protected]<mailto:[email protected]>>
Subject: Re: [OE-core] [PATCH v5] qemu: Split the qemu package

CAUTION: This email comes from a non Wind River email account!

Do not click links or open attachments unless you recognize the sender and know 
the content is safe.


On Thu, Jun 8, 2023 at 11:44 AM Richard Purdie 
<[email protected]<mailto:[email protected]>> 
wrote:
On Thu, 2023-06-08 at 11:03 -0400, Bruce Ashfield wrote:
>
>
> On Thu, Jun 8, 2023 at 9:55 AM Richard Purdie
> <[email protected]<mailto:[email protected]>>
>  wrote:
> > On Thu, 2023-06-08 at 09:33 -0400, Bruce Ashfield wrote:
> > > At this point, you can probably see why I ended up using the
> > > explicit
> > > variables and overrides versus python when doing the
> > > meta-virtualization splits. :)
> > >
> > > I have a few more comments that I made in v1, that I haven't seen
> > > directly handled or replied to.
> > >
> > > My only remaining concern (and it may just be my own concern), is
> > > that
> > > there's no way to change this packaging split. Either you take
> > > the
> > > programatic split, or you take the -all packages.
> > >
> > > Other packages (glibc, kernel-modules) have a variable that
> > > controls
> > > whether the split happens or not, I'd like to see something
> > > similar
> > > here .. but I do realize that it makes test complexity more, and
> > > that
> > > Richard normally doesn't like conditionals like that.
> >
> > I only "like" conditionals if it is a code path that will be well
> > travelled, otherwise we tend to find one of the paths is broken. I
> > don't think we need to make this conditional.
> >
> > > Alternatively, did we rule out using PACKAGESPLITFUNCS to add the
> > > splitting routine ? With that, we could remove the processing in
> > > places we don't want it, in particular for the native/sdk builds,
> > > as I
> > > found that we really don't want the splitting of qemu in those
> > > scenarios.
> >
>
>
> Can you think of a problem with the PACKAGESPLITFUNCS method for this
> packaging split ?
>
> At least that way I could inhibit it from my other layers, versus
> with this prepend, I don't see any options to have my own package
> splitting.

We can do this in a PACKAGESPLITFUNCS function. I guess I'm just
nervous of having too many different ways of packaging qemu as I was
hoping we could get something which would work for all users.


There are some very specific use cases for virtualization, where some 
separation models use different architectures for devices, even architectures 
that don't match the target (host in the running system).

There are also some combinations of usermode and system, as well as support and 
firmware, etc.

I can't see a clean/easy way to make the split being proposed here serve all 
those existing (and admittedly odd) case. Having a way to override it (even 
temporarily) is a better transition path for meta-virt.

Bruce


Cheers,

Richard


--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
its end
- "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at 
its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#182528): 
https://lists.openembedded.org/g/openembedded-core/message/182528
Mute This Topic: https://lists.openembedded.org/mt/99401176/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to