[oe] SOC_FAMILY broken

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces at lists.openembedded.org
> [mailto:openembedded-devel-bounces at lists.openembedded.org] On Behalf Of
> Leon Woestenberg
> Sent: Wednesday, September 01, 2010 4:23 PM
> To: openembedded-devel at lists.openembedded.org
> Subject: Re: [oe] SOC_FAMILY broken
> 
> Hello,
> 
> On Wed, Sep 1, 2010 at 11:14 PM, Frans Meulenbroeks
> <fransmeulenbroeks at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel