On Thu, Mar 17, 2016 at 2:02 PM, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2016-03-17 at 11:17 -0700, Andre McCurdy wrote:
>> On Thu, Mar 17, 2016 at 10:31 AM, Burton, Ross <ross.bur...@intel.com
>> > wrote:
>> >
>> > On 17 March 2016 at 17:19, Andre McCurdy <armccu...@gmail.com>
>> > wrote:
>> > >
>> > > -DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5
>> > > gobject-introspection-data"
>> > > -MACHINE_FEATURES_BACKFILL = "rtc gobject-introspection-data"
>> > > +DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5"
>> > > +MACHINE_FEATURES_BACKFILL = "rtc"
>> >
>> > So every BSP (apart from the qemu ones) would need to add the
>> > feature to
>> > MACHINE_FEATURES?
>> >
>> > Maybe we should remove from DISTRO backfill but keep backfilling
>> > for MACHINE
>> > features?
>>
>> Or don't control via a MACHINE feature at all (which would also solve
>> the package PACKAGE_ARCH issue) ?
>>
>> Each CPU tuning file would then instead need to somehow express "this
>> tuning target creates binaries which can / can't be run with qemu",
>> but maybe that's an improvement too - isn't it better to define and
>> maintain that information centrally in files controlled by oe-core
>> rather than leave it up to BSPs to get right?
>
> MACHINE_FEATURES is a variable which represents the features the target
> hardware has. There is nothing which says "this must be set in
> MACHINE.conf". In fact there is significant precedent for setting up
> common include files which define the hardware properties.
>
> If you look at one of my patches, it alters a core common include file
> to exclude introspection in a case where we can't use it (x32).
>
> So I think we actually want the same thing which is for the common tune
> files to setup the right data.
Yes, I think so.
Deciding if/how qemu can run binaries for each tuning target is
already partially addressed by the QEMU_EXTRAOPTIONS logic in
qemu.bbclass. My suggestion would be to somehow generalise that
existing logic, so (at least for machines using one of the standard
oe-core tuning files) the question "can qemu run binaries created for
${MACHINE}?" could be answered automatically.
> We have made a decision to defaulting to introspection, rightly or
> wrongly. I'm also quite happy to disable it where we know qemu can't
> work and tune files are likely the right place to that.
>
> I don't think this patchset is right.
>
> Cheers,
>
> Richard
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
