[OE-core] [PATCH 1/1] ia32-base.inc: new include file

[Richard Purdie]

On Sat, 2012-08-25 at 08:59 +0100, Phil Blundell wrote:
> On Fri, 2012-08-24 at 23:34 -0500, tom.zanussi at intel.com wrote:
> > This is the ia32-base.inc moved over from meta-intel.  See meta-intel
> > for the complete history of contributions to this file.
> > 
> > Here's the initial commit text that explains the purpose of this file:
> > 
> >   The meta-intel BSPs currently have a number of machine settings common
> >   to all - factor these out into a common include file.
> > 
> 
> It doesn't look as though the name "ia32-base" really reflects the
> contents of this file very accurately.  Most of the bits in here seem to
> have more to do with generic PC architecture and would equally apply to
> x86-64

Note that IA32 includes both x86 and x86-64 in contrast to IA64 which is
Itanium so the name is actually inclusive. 

>  (or indeed any architecture -- e.g. "ext2" which doesn't really
> seem to be a machine property in any meaningful sense).  Also, a lot of
> the stuff in this file seems rather more like distro policy than
> architecture/machine definition.
> 
> That's not to say that I think the idea of having an include file to
> capture a "PC-type" platform (or, at least, the common use-cases for
> one) is a bad idea.  If there are multiple platforms which want to do
> that then putting the definitions in a common place does seem sensible,
> but I think describing it as "ia32-base" is at the same time too
> specific and too generic.
>
> >  Also add several new intel-specific XSERVER variables for building
> >  XSERVER variables in BSPs.
> 
> If these are really intel-specific (and the i915/i965 bits do look like
> they are), shouldn't they stay in meta-intel?  It seems like having
> variables defined in oe-core, but not referenced by anything in oe-core,
> is possibly a recipe for future confusion.

They are used outside of meta-intel, just like the tune files and other
pieces we already have in OE-Core in the machine include directory. Yes,
they're only used by a subset of the architectures but I don't think
that is a reason to exclude this.

Cheers,

Richard