[PATCH 1/1] qemumips64: no qemu-usermode for n32

[PATCH 1/1] qemumips64: no qemu-usermode for n32

[Joe Slater]

qemu-usermode is only available for mips64 and o32 code.

Signed-off-by: Joe Slater <jslater@windriver.com>
---
 meta/conf/machine/qemumips64.conf | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/machine/qemumips64.conf b/meta/conf/machine/qemumips64.conf
index 3f91cbe..8feefc4 100644
--- a/meta/conf/machine/qemumips64.conf
+++ b/meta/conf/machine/qemumips64.conf
@@ -12,3 +12,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
 
 MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
+
+# no qemu-usermode for libn32
+MACHINE_FEATURES_remove_mipsarchn32 = "qemu-usermode"
+
-- 
2.7.4

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Andre McCurdy]

On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jslater@windriver.com> wrote:
> qemu-usermode is only available for mips64 and o32 code.

Isn't that already handled by meta/conf/machine/include/mips/arch-mips.inc

  # user mode qemu doesn't support mips64 n32: "Invalid ELF image for
this architecture"
  MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"

?

> Signed-off-by: Joe Slater <jslater@windriver.com>
> ---
>  meta/conf/machine/qemumips64.conf | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/conf/machine/qemumips64.conf b/meta/conf/machine/qemumips64.conf
> index 3f91cbe..8feefc4 100644
> --- a/meta/conf/machine/qemumips64.conf
> +++ b/meta/conf/machine/qemumips64.conf
> @@ -12,3 +12,7 @@ KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
>  SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
>
>  MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> +
> +# no qemu-usermode for libn32
> +MACHINE_FEATURES_remove_mipsarchn32 = "qemu-usermode"
> +
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Alexander Kanavin]

On 10/25/2017 02:43 AM, Andre McCurdy wrote:
> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jslater@windriver.com> wrote:
>> qemu-usermode is only available for mips64 and o32 code.
> 
> Isn't that already handled by meta/conf/machine/include/mips/arch-mips.inc
> 
>    # user mode qemu doesn't support mips64 n32: "Invalid ELF image for
> this architecture"
>    MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"

Yes, but this is really unreadable isn't it :) I don't see how anyone 
could grasp that the above means "remove qemu-usermode from 
MACHINE_FEATURES if n32 is in TUNE_FEATURES" (without diving into 
documentation).

Any better way to express this would be appreciated.

Alex

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Andre McCurdy]

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jslater@windriver.com> wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by meta/conf/machine/include/mips/arch-mips.inc
>>
>>    # user mode qemu doesn't support mips64 n32: "Invalid ELF image for
>> this architecture"
>>    MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone could
> grasp that the above means "remove qemu-usermode from MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot
of users - especially so since we quietly redefined it to mean not
only "functionality which used to always be enabled but is now
configurable" but now also "functionality which was not previously
enabled but is now configurable and we want to enable by default and
make it difficult for users to accidentally leave disabled".

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

I found that libn32-gobject-introspection would not compile without the remove, but I could check again.      Joe

-----Original Message-----
From: Andre McCurdy [mailto:armccurdy@gmail.com] 
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jslater@windriver.com> wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by 
>> meta/conf/machine/include/mips/arch-mips.inc
>>
>>    # user mode qemu doesn't support mips64 n32: "Invalid ELF image 
>> for this architecture"
>>    MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone 
> could grasp that the above means "remove qemu-usermode from 
> MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot of users - especially so since we quietly redefined it to mean not only "functionality which used to always be enabled but is now configurable" but now also "functionality which was not previously enabled but is now configurable and we want to enable by default and make it difficult for users to accidentally leave disabled".

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

Okay, I don't know why, but at the time of backfilling the CONSIDERED list is empty!  This is not true if I use "=" to set it unconditionally in arch-mips.inc, but it IS true if I try to set it via anything involving an override (including append).

Isn't getVar() supposed to expand the variable?  Put print msg's in meta/lib/oe/utils.py to see this behavior.

Joe

________________________________________
From: Slater, Joseph
Sent: Wednesday, October 25, 2017 11:24 AM
To: Andre McCurdy; Alexander Kanavin
Cc: OE Core mailing list
Subject: RE: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

I found that libn32-gobject-introspection would not compile without the remove, but I could check again.      Joe

-----Original Message-----
From: Andre McCurdy [mailto:armccurdy@gmail.com]
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jslater@windriver.com> wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by
>> meta/conf/machine/include/mips/arch-mips.inc
>>
>>    # user mode qemu doesn't support mips64 n32: "Invalid ELF image
>> for this architecture"
>>    MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone
> could grasp that the above means "remove qemu-usermode from
> MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot of users - especially so since we quietly redefined it to mean not only "functionality which used to always be enabled but is now configurable" but now also "functionality which was not previously enabled but is now configurable and we want to enable by default and make it difficult for users to accidentally leave disabled".

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Andre McCurdy]

On Thu, Oct 26, 2017 at 10:15 AM, Slater, Joseph
<joe.slater@windriver.com> wrote:
> Okay, I don't know why, but at the time of backfilling the CONSIDERED list is empty!  This is not true if I use "=" to set it unconditionally in arch-mips.inc, but it IS true if I try to set it via anything involving an override (including append).
>
> Isn't getVar() supposed to expand the variable?  Put print msg's in meta/lib/oe/utils.py to see this behavior.

features_backfill() is called from meta/classes/base.bbclass ->
base_eventhandler() in response to bb.event.ConfigParsed (ie "when the
base configuration; which consists of bitbake.conf, base.bbclass and
any global INHERIT statements; has been parsed") so anything assigned
to DISTRO_FEATURES_BACKFILL_CONSIDERED or
MACHINE_FEATURES_BACKFILL_CONSIDERED after that event won't be seen...

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

I think values for the BACKFILL_CONSIDERED can be used, but only if they are literals.  I don't think any variable expansion occurs when getVar() is used at the point of backfilling.  I think the a better way of setting MACHINE or DISTRO_FEATURES would be to directly append/remove  using overrides.  In any case, I do not believe any of the CONSIDERED definitions work.

Joe

-----Original Message-----
From: Andre McCurdy [mailto:armccurdy@gmail.com] 
Sent: Thursday, October 26, 2017 11:09 AM
To: Slater, Joseph
Cc: Alexander Kanavin; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Thu, Oct 26, 2017 at 10:15 AM, Slater, Joseph <joe.slater@windriver.com> wrote:
> Okay, I don't know why, but at the time of backfilling the CONSIDERED list is empty!  This is not true if I use "=" to set it unconditionally in arch-mips.inc, but it IS true if I try to set it via anything involving an override (including append).
>
> Isn't getVar() supposed to expand the variable?  Put print msg's in meta/lib/oe/utils.py to see this behavior.

features_backfill() is called from meta/classes/base.bbclass ->
base_eventhandler() in response to bb.event.ConfigParsed (ie "when the base configuration; which consists of bitbake.conf, base.bbclass and any global INHERIT statements; has been parsed") so anything assigned to DISTRO_FEATURES_BACKFILL_CONSIDERED or MACHINE_FEATURES_BACKFILL_CONSIDERED after that event won't be seen...

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Andre McCurdy]

On Thu, Oct 26, 2017 at 1:51 PM, Slater, Joseph
<joe.slater@windriver.com> wrote:
> I think values for the BACKFILL_CONSIDERED can be used, but only if they are literals.  I don't think any variable expansion occurs when getVar() is used at the point of backfilling.

Maybe the assumption is that MACHINE_FEATURES_BACKFILL_CONSIDERED will
only be set from the machine config and
DISTRO_FEATURES_BACKFILL_CONSIDERED will only be set from the distro
config. Don't they work even in that case?

> I think the a better way of setting MACHINE or DISTRO_FEATURES would be to directly append/remove  using overrides.

Yes, of course. If you want to control machine or distro features
directly that that's the way it should be done. The BACKFILL
infrastructure is there for a very special case - to try to keep a
consistent behaviour for users who set fixed values for machine or
distro features and don't keep those definitions up to date with
changes in oe-core.

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Alexander Kanavin]

On 10/26/2017 11:51 PM, Slater, Joseph wrote:
> I think values for the BACKFILL_CONSIDERED can be used, but only if they are literals.  I don't think any variable expansion occurs when getVar() is used at the point of backfilling.  I think the a better way of setting MACHINE or DISTRO_FEATURES would be to directly append/remove  using overrides.  In any case, I do not believe any of the CONSIDERED definitions work.

We use the same-style disabling of qemu-usermode in other machine 
definitions (powerpc64, x86 x32), and they do seem to work there. 
Something's not right here.


Alex

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

Could be a multilib issue.  I do see that these constructs work in a poky build environment.  Are there any "standard" configurations that enable multilib?  I am typically building in a (surprise!) Wind River build environment which does support multilib.

Joe
________________________________________
From: Alexander Kanavin [alexander.kanavin@linux.intel.com]
Sent: Friday, October 27, 2017 2:13 AM
To: Slater, Joseph; Andre McCurdy
Cc: OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On 10/26/2017 11:51 PM, Slater, Joseph wrote:
> I think values for the BACKFILL_CONSIDERED can be used, but only if they are literals.  I don't think any variable expansion occurs when getVar() is used at the point of backfilling.  I think the a better way of setting MACHINE or DISTRO_FEATURES would be to directly append/remove  using overrides.  In any case, I do not believe any of the CONSIDERED definitions work.

We use the same-style disabling of qemu-usermode in other machine
definitions (powerpc64, x86 x32), and they do seem to work there.
Something's not right here.


Alex

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Alexander Kanavin]

On 10/31/2017 02:39 AM, Slater, Joseph wrote:
> Could be a multilib issue.  I do see that these constructs work in a poky build environment.  Are there any "standard" configurations that enable multilib?  I am typically building in a (surprise!) Wind River build environment which does support multilib.
> 

Can you share your multilib config then and steps to trigger the 
failure? Does it happen in a plain poky environment?

Alex

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Mark Hatle]

On 10/31/17 4:41 AM, Alexander Kanavin wrote:
> On 10/31/2017 02:39 AM, Slater, Joseph wrote:
>> Could be a multilib issue.  I do see that these constructs work in a poky build environment.  Are there any "standard" configurations that enable multilib?  I am typically building in a (surprise!) Wind River build environment which does support multilib.
>>
> 
> Can you share your multilib config then and steps to trigger the 
> failure? Does it happen in a plain poky environment?

Edit your local.conf, add the following:

MULTILIBS ?= ""
require conf/multilib.conf
MULTILIB_GLOBAL_VARIANTS_append = " libn32"
MULTILIBS ?= "multilib:lib32 multilib:libn32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"

(note, we have this implemented in the -distro.conf- file.  But it should behave
the same in the local.conf)

--Mark

> Alex
> 

Re: [PATCH 1/1] qemumips64: no qemu-usermode for n32

[Mark Hatle]

On 10/31/17 8:37 AM, Mark Hatle wrote:
> On 10/31/17 4:41 AM, Alexander Kanavin wrote:
>> On 10/31/2017 02:39 AM, Slater, Joseph wrote:
>>> Could be a multilib issue.  I do see that these constructs work in a poky build environment.  Are there any "standard" configurations that enable multilib?  I am typically building in a (surprise!) Wind River build environment which does support multilib.
>>>
>>
>> Can you share your multilib config then and steps to trigger the 
>> failure? Does it happen in a plain poky environment?
> 
> Edit your local.conf, add the following:
> 
> MULTILIBS ?= ""
> require conf/multilib.conf
> MULTILIB_GLOBAL_VARIANTS_append = " libn32"
> MULTILIBS ?= "multilib:lib32 multilib:libn32"
> DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
> DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"

Sorry I just realized what I have above is out of order.  Below is corrected:

MULTILIB_GLOBAL_VARIANTS_append = " libn32"
MULTILIBS ?= "multilib:lib32 multilib:libn32"
DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"
MULTILIBS ?= ""
require conf/multilib.conf

(again this is specific to qemumips64)

--Mark

> (note, we have this implemented in the -distro.conf- file.  But it should behave
> the same in the local.conf)
> 
> --Mark
> 
>> Alex
>>
>