Re: qemuarm: should it really have TUNE_ARCH armv5te?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2012-09-13 at 08:20 +0200, Martin Jansa wrote:
> On Wed, Sep 12, 2012 at 03:33:03PM +0100, Richard Purdie wrote:
> > On Tue, 2012-09-11 at 15:01 +0200, Martin Jansa wrote:
> > > Hi,
> > > 
> > > when building spitz and qemuarm (both produces packages in armv5te feed)
> > > resulting packages are tuned with -mtune=xscale (when built for spitz) 
> > > or -mtune=arm926ej-s (when built for qemuarm).
> > > 
> > > From
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=1916#c5
> > > Firstly, if you go changing the tune parameters in a given machine,
> > > you are expected to use a different PACKAGE_ARCH. If you do that, you
> > > will get a different package feed for the different binaries,
> > > different WORKDIR and so on. This was always the way the package
> > > architectures was intended to work and nothing has changed there. Yes,
> > > you as the user changing various variables can create inconsistent
> > > package feeds. There are 101 ways you can do that, the simple answer
> > > is just don't. We're therefore unlikely to add MACHINE to DEPLOY_DIR
> > > or remove PACKAGE_ARCH, please just use it as its intended.
> > > 
> > > Does qemuarm use oe-core as it's intended?
> > > 
> > > Shouldn't spitz produce something like armv5te-xscale and qemuarm armv5te-arm926ejs?
> > > It would cause all recipes to build again (cannot share armv5te feed anymore),
> > > but at least it would build it and user will really get it on target, right now
> > > opkg upgrade can download some packages with xscale some with arm926ej-s.
> > > 
> > > $ ~/bitbake/bin/bitbake-diffsigs
> > >   stamps.1347348910/spitz/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.04b364a15889fcff7502614f1c116abc
> > >   stamps.1347348910/qemuarm/armv5te-oe-linux-gnueabi/linux-libc-headers-3.4.3-r0.do_configure.sigdata.656f0583be969b427f040f2e143bcb14
> > >   basehash changed from 7fe9c0a3455dac20ba6a90ed337b097e to d8dd2ff8613d0aafe60bef1a1e9469a1
> > >   Variable TUNE_CCARGS value changed from
> > >   ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "xscale", "-mtune=xscale", "", d)}
> > >   to
> > >   ${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}
> > >   ${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}
> > > 
> > 
> > This is a tricky one. As others have mentioned, this is a tune
> > parameter, not an arch one and as such the binaries are compatible with
> > each other although they potentially are compiled differently with
> > different optimisations.
> > 
> > As such, mixing the feeds is permitted and will not cause any real world
> > usage problem. As you point out, sstate is much more sensitive to this
> > kind of change and is correctly deciding the output is different though.
> > 
> > I think my preferred approach would be to have the tune files do
> > something like:
> > 
> > -mtune=${ARMV5TEDEFAULTTUNE}
> > 
> > and then the user can set ARMV5DEFAULTTUNE to whatever the believe is a
> > appropriate. This would result in the package feed at least having a
> > consistent state of one tune and sstate would be happy. It then becomes
> > a distro policy decision which is what it should be. ARMV5TEDEFAULTTUNE
> > would default to the current values meaning the distro would then just
> > do:
> > 
> > ARMV5TEDEFAULTTUNE_poky = "xscale"
> >
> > and hence make their decision. Of course the distro could also decide to
> > split the package architectures up which is equally fine.
> > 
> > Does something like that sound like it would work?
> 
> My solution seems to be a bit more flexible then this.

Which cases does it enable which the above doesn't?

I'm a little worried about adding more indirection to the DEFAULTTUNE
variable itself since the whole tune situation is already convoluted and
indirected enough without adding another level of it :/. That variable
is the one exposed to the user straight away, not hidden more behind the
scenes.

Taking a step back and looking at the APIs I'm really not very happy
with the usability of them already and I don't think this helps.

Someone commented about the ppc situation and I was told that there, the
binaries are incompatible with each other. It is more unusual to have
situations where there are micro-optimisations through -mtune yet the
binaries remain compatible.

Cheers,

Richard