On Thu, Sep 27, 2012 at 02:53:21PM -0500, Mark Hatle wrote:
> On 9/27/12 2:40 PM, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 02:18:07PM -0500, Mark Hatle wrote:
> >> On 9/27/12 2:12 PM, Martin Jansa wrote:
> >>> On Thu, Sep 27, 2012 at 01:58:35PM -0500, Mark Hatle wrote:
> >>>> Let me preface this by I have read the patch set.. Martin asked me to
> >>>> comment on
> >>>> the items below...
> >>>>
> >>>> On 9/27/12 3:37 AM, Martin Jansa wrote:
> >>>>> On Sat, Sep 22, 2012 at 06:45:44PM +0100, Richard Purdie wrote:
> >>>>>> On Sat, 2012-09-22 at 18:51 +0200, Martin Jansa wrote:
> >>>>>>> * bitbake.conf has OPTDEFAULTTUNE with weak default value of
> >>>>>>> DEFAULTTUNE
> >>>>>>> * this way xscale or arm926ejs is not used by default when some
> >>>>>>> machine
> >>>>>>> includes its tune*.inc, but it's easy for DISTRO to say it wants
> >>>>>>> OPTDEFAULTTUNE for some packages or always (if they don't want to
> >>>>>>> share built packages between xscale and arm926ejs).
> >>>>>>>
> >>>>>>> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> >>>>>>> ---
> >>>>>>> meta/conf/bitbake.conf | 1 +
> >>>>>>> meta/conf/machine/include/tune-arm926ejs.inc | 3 ++-
> >>>>>>> meta/conf/machine/include/tune-xscale.inc | 3 ++-
> >>>>>>> 3 files changed, 5 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >>>>>>> index 9b41749..e433fcb 100644
> >>>>>>> --- a/meta/conf/bitbake.conf
> >>>>>>> +++ b/meta/conf/bitbake.conf
> >>>>>>> @@ -95,6 +95,7 @@ HOST_LD_ARCH = "${TARGET_LD_ARCH}"
> >>>>>>> HOST_AS_ARCH = "${TARGET_AS_ARCH}"
> >>>>>>> HOST_EXEEXT = ""
> >>>>>>>
> >>>>>>> +OPTDEFAULTTUNE ??= "${DEFAULTTUNE}"
> >>>>>>> TUNE_ARCH ??= "INVALID"
> >>>>>>> TUNE_CCARGS ??= ""
> >>>>>>> TUNE_LDARGS ??= ""
> >>>>>>
> >>>>>> As I've said previously, I do not think OPTDEFAULTTUNE is clear in
> >>>>>> usage
> >>>>>> or in meaning and we need to find a better solution. I'm therefore not
> >>>>>> keen on this change.
> >>>>>
> >>>>> OK, what about the rest of patchset (without OPTDEFAULTTUNE bits) to use
> >>>>> different PKGARCH for different TUNE_CCARGS?
> >>>>
> >>>> I've been an advocate for a while that the processor optimization
> >>>> (CCARGS) does
> >>>> make it into the PKGARCH. ARMPKGSFX_CPU seems like a reasonable
> >>>> approach to do
> >>>> this. It allows each tune to set something to tell people what that
> >>>> binary is
> >>>> really built for, and for the 'base' tunes (i.e. armv5) it can be left
> >>>> off.
> >>>>
> >>>> The only concern I have with that is:
> >>>>
> >>>> +ARMPKGSFX_CPU = "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs",
> >>>> "-arm926ejs", "", d)}"
> >>>>
> >>>> That probably should be a .= instead of just '='. That way if the user
> >>>> loads
> >>>> multiple compatible tunes the right ARMPKGSFX_CPU will be used.
> >>>> (Alternatively
> >>>> using the overrides would work as well for this.. i.e.
> >>>> ARMPKGSFX_CPU_tune-arm926ejs instead...
> >>>
> >>> OK.
> >>>
> >>>> I see Patch 5/5 instead moves toward the ARMPKGARCH usage instead...
> >>>> This is
> >>>> fine as well, and it was designed to be overriden.. but again the .= or
> >>>> -tune_... syntax should be used...
> >>>
> >>> I tend to prefer ARMPKGARCH as it's shorter xscale-te/armv5te-xscale.
> >>>
> >>> But not sure what to do with all "lower" PACKAGE_EXTRA_ARCHS:
> >>> PACKAGE_EXTRA_ARCHS_tune-xscale-be =
> >>> "${PACKAGE_EXTRA_ARCHS_tune-armv5teb}"
> >>> do we want PACKAGE_EXTRA_ARCHS_tune-armv5teb only or also something like
> >>> armv4t-xscale?
> >>>
> >>> Well whole PACKAGE_EXTRA_ARCHS has too many entries already (opkg update
> >>> would try to download many feeds but only a few does exist).
> >>
> >> The PACKAGE_EXTRA_ARCHS should contain all of the 'compatible' arch names.
> >> Which of course feed into the list of feeds used by the various packaging
> >> systems. I think it's up to the distribution to modify or limit the feeds
> >> resolved, but I don't know if there is a clean way to do this. I always
> >> error
> >> on listing more then less, because I don't know how people are going to
> >> want to
> >> mix and match things. (And a BSP or end user can always just define what
> >> the
> >> PACKAGE_EXTRA_ARCHS value should be.)
> >
> > Yes that's what I do now, but I'm not too happy about it :/
> > SUPPORTED_EXTRA_ARCHS ?= "armv4t armv5te armv6-novfp armv7a-vfp-neon x86_64
> > x86"
> > SUPPORTED_EXTRA_ARCHS_armv7a ?= "armv7a-vfp-neon"
> > SUPPORTED_EXTRA_ARCHS_armv6 ?= "armv6-novfp"
> >
> >>>> Anyway, my point in this is I like having the stuff unique, but we need
> >>>> to be
> >>>> sure that you can specify more then one tune file during a build w/o
> >>>> clashes.
> >>>>
> >>>>>> I also still think this is a distro packaging issue and should be
> >>>>>> solved
> >>>>>> by the distro, even if that means more complexity there. That is the
> >>>>>> right place for this particular complexity IMO. I'm happy to support
> >>>>>> that from the core but not in something as user visible and confusing
> >>>>>> as
> >>>>>> this variable.
> >>>>>
> >>>>> Agreed OPTDEFAULTTUNE is to help distro configs, because complexity
> >>>>> there will be much worse then when it's defined in tune-* files, because
> >>>>> now will have to define DEFAULTTUNE/OPTDEFAULTTUNE for each MACHINE (or
> >>>>> TUNE_FEATURE) it supports and it's less orthogonal (machine/distro
> >>>>> config) then it could be.
> >>>>
> >>>> I really don't have a strong opinion on this either way. I know for the
> >>>> stuff
> >>>> I've done in the past (not oe-based) we've just manually configured (the
> >>>> equivalent of the distro conf) with the information on the handful of
> >>>> items that
> >>>> people wanted optimized the most... eglibc, openssl, mysql/posgresql...
> >>>> otherwise folks don't seem to care, and re-use works fine.
> >>>>
> >>>> If the list is small (i.e. less then 10 packages) that specifying it via
> >>>> package
> >>>> specific overrides in the distro file should be fine.. if it's more then
> >>>> 10
> >>>> (typically) then we need to start looking for another approach.
> >>>>
> >>>> I'd almost suggest in the distro file you could do:
> >>>>
> >>>> OPTDEFAULTTUNE = "$@{...}" where ... is check for something set by the
> >>>> BSP (or
> >>>> elsewhere), if set use that value, otherwise using the DEFAULTTUNE value.
> >>>>
> >>>> DEFAULTTUNE-<pn> = "${OPTDEFAULTTUNE}"
> >>>
> >>> Yes but first I have to say:
> >>> DEFAULTTUNE_spitz = armv5te
> >>> OPTDEFAULTTUNE_spitz = xscale
> >>> DEFAULTTUNE_qemuarm = armv5te
> >>> OPTDEFAULTTUNE_qemuarm = arm926ejs
> >>> or
> >>> DEFAULTTUNE_tune-xscale = armv5te
> >>> OPTDEFAULTTUNE_tun_xscale = xscale
> >>> DEFAULTTUNE_tune-arm926ejs = armv5te
> >>> OPTDEFAULTTUNE_tune-arm926ejs = arm926ejs
> >>>
> >>> to know what's OPTDEFAULTTUNE and DEFAULTTUNE for given MACHINE if it's
> >>> not in defined tune-xscale/tune-arm926ejs.
> >>
> >> I assume that a distribution will be (bb)appending, or defining their own
> >> BSPs.
> >> And in that case it's pretty easy to add both the DEFAULTTUNE and
> >> OPTDEFAULTTUNE line to the BSP configuration file. (And if someone uses a
> >> different distribution, then the DEFAULT is used as that is the standard
> >> method.)
> >
> > Yes, but how should I .bbappend machine config? e.g. qemuarm.conf in
> > oe-core?
>
> Sorry, not bbappend in this case.. but you can do it in a distribution
> layer.
> (This is from memory so I might not be 100% correct.)
>
> You should be able to have in your own layer a qemuarm.conf that looks like:
>
> require conf/machine/qemuarm.conf
> OPTDEFAULTTUNE = "something"
> DEFAULTTUNE = "something_else"
>
> It will know not to open itself in the requires.... and fall back to a
> previous
> layer.
>
> (If that doesn't work, I know we did it somehow.. since we ran into a similar
> situation with our product.)yes but that's still at least 2 more lines (possibly in separate .conf file) for each MACHINE I could possibly support by my distro, I would like to keep it more universal (or ortogonal in distro/machine/image sense). > > Yes I can add that to my BSPs, but if I call it OPTDEFAULTTUNE > > then everybody else (who is interested in my BSP but has own distro) > > needs to agree on name OPTDEFAULTTUNE. > > > > That's why I wanted this defined in tune-* files which are shared in > > oe-core and used by everybody I guess. > > I agree completely, this is the downside of doing it int he distro files vs > the > tune files. But in the end it seems reasonable to make it a machine or > distribution setting of some kind. > > >>> And that's what I didn't want to include in my distro config (and then > >>> explaining to someone that when adding MACHINE foo he has to send patch > >>> for distro config). > >> > >> Ya I understand. This is an odd situation for many embedded systems. You > >> want > >> to reuse packages that aren't optimally tuned -- but you still want a few > >> tuned > >> packages. It's certainly a usecase we need to support -- but I'm not sure > >> in > >> the end how people end up doing this. > >> > >> I know most of my commercial customers just want everything to be tuned > >> for the > >> target BSP.. and they build new distributions for each product they > >> implement. > > > > Ok, but having both OPTDEFAULTTUNE and DEFAULTTUNE in tune-* allows both > > use cases to coexist without any complex configuration on distro side. > > Yup, no disagreement there. Ok, lets see if this changes RP's view on OPTDEFAULTTUNE. Cheers, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
