SOC_FAMILY broken

SOC_FAMILY broken

[Frans Meulenbroeks]

Patch http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=07076390358f211bd96779bec2d6eb5eaa0ad699
creates errors like:
ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime
entity 'virtual/arm-oe-linux-gnueabi-gcc-2.95' but it wasn't found in
any PACKAGE or RPROVIDES variables

Root cause: if SOC_FAMILY is not set (awhich is the case for most
MACHINEs  and all distro's except angstrom) the test in base.bbclass
to skip recipes for different machines never raises the SkipPackage
exception.

This is the current code (about line 387 in base.bbclass):
        need_machine = bb.data.getVar('COMPATIBLE_MACHINE', d, 1)
        if need_machine:
            import re
            this_machine = bb.data.getVar('MACHINE', d, 1)
            if this_machine and not re.match(need_machine, this_machine):
                this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
                if this_soc_family and not re.match(need_machine,
this_soc_family):
                    raise bb.parse.SkipPackage("incompatible with
machine %s" % this_machine)

I see two possible fixes.
1. Make sure SOC_FAMILY is always defined. E.g. in bitbake.conf say
SOC_FAMILY ?= "Unknown"
2. improve the test to deal with an undefined soc_famile
E.g rewrite the one but last line to:
                    if (this_soc_family and not re.match(need_machine,
this_soc_family)) or not this_soc_family:

I tested the 2nd patch with distro minimal, target sheevaplug, which
gave the error before. After rewriting the line as suggested skipping
works and the problem is gone.
I have this also as a formal patch, but there might be more desirable
ways to do this.

Please advise.

Frans.

Re: SOC_FAMILY broken

[Leon Woestenberg]

Hello,

On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Root cause: if SOC_FAMILY is not set (awhich is the case for most
> MACHINEs  and all distro's except angstrom) the test in base.bbclass
>

Good point, but I never understood SOC_FAMILY. From an old email:

"SOC_FAMILY is defining a family of processors and the features that processor
has.  Whereas MACHINE_CLASS is defining a type of device and its features which
can use different processors."

I think the first sentence is contradicting itself.

A "family of processors" vs. "features that processor had". This can
be fully orthogonal (worst case),
so the definition of the variable is crap. I wonder, has it proven
more useful than cumbersome?

If it truly has a clear function in OpenEmbedded that can apply to all
processors, can someone explain what the variable should be set to?


Regards,
-- 
Leon

Re: SOC_FAMILY broken

[Michael 'Mickey' Lauer]

Am Mittwoch, den 01.09.2010, 23:22 +0200 schrieb Leon Woestenberg:
> On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
> > Root cause: if SOC_FAMILY is not set (awhich is the case for most
> > MACHINEs  and all distro's except angstrom) the test in base.bbclass
> >
> 
> Good point, but I never understood SOC_FAMILY. From an old email:
> 
> "SOC_FAMILY is defining a family of processors and the features that processor
> has.  Whereas MACHINE_CLASS is defining a type of device and its features which
> can use different processors."
> 
> I think the first sentence is contradicting itself.
> 
> A "family of processors" vs. "features that processor had". This can
> be fully orthogonal (worst case),
> so the definition of the variable is crap. I wonder, has it proven
> more useful than cumbersome?

I still don't know why we need both SOC_FAMILY and MACHINE_CLASS in the
first place. MACHINE_CLASS has been around for much longer and if you
look how it's being used or intended to use, you see that there are
hardly any processor differences in the members of those classes (e.g.
openezx, qualcomm msm7, om-gta01/02, clamshell zaurus models, ...).

I'm still unconvinced that we need both variables.

Cheers,
-- 
:M:

Re: SOC_FAMILY broken

[Frans Meulenbroeks]

2010/9/2 Michael 'Mickey' Lauer <mickey@vanille-media.de>:
> Am Mittwoch, den 01.09.2010, 23:22 +0200 schrieb Leon Woestenberg:
>> On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>> > Root cause: if SOC_FAMILY is not set (awhich is the case for most
>> > MACHINEs  and all distro's except angstrom) the test in base.bbclass
>> >
>>
>> Good point, but I never understood SOC_FAMILY. From an old email:
>>
>> "SOC_FAMILY is defining a family of processors and the features that processor
>> has.  Whereas MACHINE_CLASS is defining a type of device and its features which
>> can use different processors."
>>
>> I think the first sentence is contradicting itself.
>>
>> A "family of processors" vs. "features that processor had". This can
>> be fully orthogonal (worst case),
>> so the definition of the variable is crap. I wonder, has it proven
>> more useful than cumbersome?
>
> I still don't know why we need both SOC_FAMILY and MACHINE_CLASS in the
> first place. MACHINE_CLASS has been around for much longer and if you
> look how it's being used or intended to use, you see that there are
> hardly any processor differences in the members of those classes (e.g.
> openezx, qualcomm msm7, om-gta01/02, clamshell zaurus models, ...).
>
> I'm still unconvinced that we need both variables.

Neither do I.
Also it has been requested during the review (if I recall correctly by
Tom) to provide documentation, but sadly enough that review comment
was ignored and the change pushed anyway.
Perhaps we should make explicit that the introduction of a new user
var also must come with the associated documentation.

Frans

Re: SOC_FAMILY broken

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Leon Woestenberg
> Sent: Wednesday, September 01, 2010 4:23 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] SOC_FAMILY broken
> 
> Hello,
> 
> On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
> > Root cause: if SOC_FAMILY is not set (awhich is the case for most
> > MACHINEs  and all distro's except angstrom) the test in base.bbclass
> >
> 
> Good point, but I never understood SOC_FAMILY. From an old email:
> 
> "SOC_FAMILY is defining a family of processors and the features that
> processor
> has.  Whereas MACHINE_CLASS is defining a type of device and its features
> which
> can use different processors."
> 
> I think the first sentence is contradicting itself.
> 
> A "family of processors" vs. "features that processor had". This can
> be fully orthogonal (worst case),
> so the definition of the variable is crap. I wonder, has it proven
> more useful than cumbersome?

What this is saying is the SOC_FAMILY defines a family of processors that all share common features, i.e. the OMAP3 family.  These processors will agree on many things such as kernel recipes, bootloaders, etc.  However, they will also have some differences such as whether they support wireless, etc.  Thus they have separate machine types but share an SOC_FAMILY type.  This way we do not need to specify overrides for every omap3 machine type of which a rough count shows there to be 19.

My understanding of MACHINE_CLASS on the other hand is that this is to group devices by the type of end product being made.  i.e. a cell phone vs a hand-held media player.  In this case you could have very different processors for these devices, but they all agree on the features that the device has in common.  There was a discussion about this previously in which Graeme said:

"As the person who originally added MACHINE_CLASS to openmoko and the OE,
then removed it from OE I can say it has different meaning that
SOC_FAMILY. MACHINE_CLASS was to identify a range of machines that were
90% the same but had a few differences. It was used in a few recipes
which were MACHINE_ARCH to make them use the same ARCH in these recipes
to stop them being rebuilt when switching machines."

I hope this answers your questions.  I didn't add the SOC_FAMILY but I can tell you that I use it quite a lot.

It looks to me that the micro, shr, and minimal distros still have MACHINE_CLASS in their overrides, and that the htc-msm7, motorola-ezx-base, and htc-qsd8 devices actually define a machine type.

The htc-msm7 and htc-qsd9 machine classes do not appear to be used in the OE mainline (but perhaps in someone's overlay)

The motorola-ezx machine class is used in pulseaudio to set the default preference to -1.


Again, thanks for finding and fixing this issue.

> 
> If it truly has a clear function in OpenEmbedded that can apply to all
> processors, can someone explain what the variable should be set to?
> 
> 
> Regards,
> --
> Leon
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: SOC_FAMILY broken

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Wednesday, September 01, 2010 4:15 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] SOC_FAMILY broken
> 
> Patch
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=07076390358f
> 211bd96779bec2d6eb5eaa0ad699
> creates errors like:
> ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime
> entity 'virtual/arm-oe-linux-gnueabi-gcc-2.95' but it wasn't found in
> any PACKAGE or RPROVIDES variables
> 
> Root cause: if SOC_FAMILY is not set (awhich is the case for most
> MACHINEs  and all distro's except angstrom) the test in base.bbclass
> to skip recipes for different machines never raises the SkipPackage
> exception.
> 
> This is the current code (about line 387 in base.bbclass):
>         need_machine = bb.data.getVar('COMPATIBLE_MACHINE', d, 1)
>         if need_machine:
>             import re
>             this_machine = bb.data.getVar('MACHINE', d, 1)
>             if this_machine and not re.match(need_machine, this_machine):
>                 this_soc_family = bb.data.getVar('SOC_FAMILY', d, 1)
>                 if this_soc_family and not re.match(need_machine,
> this_soc_family):
>                     raise bb.parse.SkipPackage("incompatible with
> machine %s" % this_machine)
> 
> I see two possible fixes.
> 1. Make sure SOC_FAMILY is always defined. E.g. in bitbake.conf say
> SOC_FAMILY ?= "Unknown"
> 2. improve the test to deal with an undefined soc_famile
> E.g rewrite the one but last line to:
>                     if (this_soc_family and not re.match(need_machine,
> this_soc_family)) or not this_soc_family:
> 
> I tested the 2nd patch with distro minimal, target sheevaplug, which
> gave the error before. After rewriting the line as suggested skipping
> works and the problem is gone.
> I have this also as a formal patch, but there might be more desirable
> ways to do this.
> 
> Please advise.

I like your second proposal.  Thanks for finding this issue and a solution to it.

> 
> Frans.
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel