From: Saul Wold <saul.wold@intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Cc: McClintock Matthew-B29882 <B29882@freescale.com>
Subject: Re: [PATCH 07/16] Fix lttng-ust for powerpc64
Date: Fri, 30 Sep 2011 09:58:19 -0700 [thread overview]
Message-ID: <4E85F52B.2010000@intel.com> (raw)
In-Reply-To: <1317321967.12332.113.camel@ted>
On 09/29/2011 11:46 AM, Richard Purdie wrote:
> On Thu, 2011-09-29 at 18:21 +0000, McClintock Matthew-B29882 wrote:
>> On Thu, Sep 29, 2011 at 10:50 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Wed, 2011-09-28 at 23:21 -0500, Matthew McClintock wrote:
>>>> Signed-off-by: Matthew McClintock<msm@freescale.com>
>>>> ---
>>>> meta/recipes-kernel/lttng/fix-powerpc64.patch | 17 +++++++++++++++++
>>>> meta/recipes-kernel/lttng/lttng-ust_0.15.bb | 3 ++-
>>>> 2 files changed, 19 insertions(+), 1 deletions(-)
>>>> create mode 100644 meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>>
>>>> diff --git a/meta/recipes-kernel/lttng/fix-powerpc64.patch b/meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>> new file mode 100644
>>>> index 0000000..d347979
>>>> --- /dev/null
>>>> +++ b/meta/recipes-kernel/lttng/fix-powerpc64.patch
>>>> @@ -0,0 +1,17 @@
>>>> +Upstream-Status: Inappropriate configuration
>>>
>>> Is this really inappropriate for upstream? It looks reasonable to me...
>>
>> Seems reasonable. What is the policy on this? Can I mark it "this
>> should be upstreamed" or must I mark it "this was sent upstream" and
>> then upstream the change?
>
> There is some marking for "should be upstreamed"/upstreamable.
>
The marking would be "Pending", this indicates that it should be
attempted, if it gets up streamed then marked Accepted with a pointer to
the potential upstream version or ref.
Thanks
Sau!
>>>> +Add bit to detect if we are running on powerpc64 and treat it the
>>>> +same as ppc64
>>>> +
>>>> +Index: ust-0.15/configure.ac
>>>> +===================================================================
>>>> +--- ust-0.15.orig/configure.ac
>>>> ++++ ust-0.15/configure.ac
>>>> +@@ -111,6 +111,7 @@ changequote([,])dnl
>>>> + x86_64) LIBFORMAT="elf64-x86-64" ;;
>>>> + powerpc) LIBFORMAT="elf32-powerpc" ;;
>>>> + ppc64) LIBFORMAT="elf64-powerpc" ;;
>>>> ++ powerpc64) LIBFORMAT="elf64-powerpc" ;;
>>>> + s390) LIBFORMAT="elf32-s390" ;;
>>>> + s390x) LIBFORMAT="elf64-s390" ;;
>>>> + armv5) LIBFORMAT="elf32-littlearm"; NO_UNALIGNED_ACCESS=1 ;;
>>>> diff --git a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> index 915e619..9dd4658 100644
>>>> --- a/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> +++ b/meta/recipes-kernel/lttng/lttng-ust_0.15.bb
>>>> @@ -10,9 +10,10 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=e647752e045a8c45b6f583771bd561ef \
>>>>
>>>> DEPENDS = "liburcu"
>>>>
>>>> -PR = "r2"
>>>> +PR = "r3"
>>>>
>>>> SRC_URI = "http://lttng.org/files/ust/releases/ust-${PV}.tar.gz"
>>>> +SRC_URI_append_powerpc64 = " file://fix-powerpc64.patch"
>>>
>>> Does this really need to be conditional on powerppc64? Looks like it can
>>> be applied unconditionally...
>>
>> True, was trying to minimally effect other stuff. But I take it by the
>> comment you prefer this be done away with.
>
> Sometimes minimally affecting other code is good. In this its obviously
> not going to break anything else so it can be universal. The risk of
> minimal application is fewer people testing it, e.g. when versions get
> upgraded.
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
next prev parent reply other threads:[~2011-09-30 17:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 4:20 [PATCH 01/16] libnl2: Fix a race on route/pktloc_syntax.h Matthew McClintock
2011-09-29 4:20 ` [PATCH 02/16] bitbake pseudo wrapper: Don't base success on bitbake return code Matthew McClintock
2011-09-29 8:26 ` Richard Purdie
2011-09-29 18:04 ` McClintock Matthew-B29882
2011-09-29 18:27 ` Richard Purdie
2011-09-29 18:30 ` McClintock Matthew-B29882
2011-09-29 4:20 ` [PATCH 03/16] Update gitignore to ignore all meta-* directories Matthew McClintock
2011-09-29 6:45 ` Dmitry Eremin-Solenikov
2011-09-29 4:20 ` [PATCH 04/16] Add support for generating ext2.bz2{, .u-boot} images Matthew McClintock
2011-09-29 4:20 ` [PATCH 05/16] Add support for generating ext2.lzma{, " Matthew McClintock
2011-09-29 4:21 ` [PATCH 06/16] Fix perl for powerpc64 build Matthew McClintock
2011-09-29 4:21 ` [PATCH 07/16] Fix lttng-ust for powerpc64 Matthew McClintock
2011-09-29 15:50 ` Richard Purdie
2011-09-29 18:21 ` McClintock Matthew-B29882
2011-09-29 18:46 ` Richard Purdie
2011-09-30 16:58 ` Saul Wold [this message]
2011-09-30 17:19 ` McClintock Matthew-B29882
2011-09-29 4:21 ` [PATCH 08/16] Fixup kexec-tools compatible host for powerpc Matthew McClintock
2011-09-29 4:21 ` [PATCH 09/16] Add autoconf cache for screen on powerpc64 Matthew McClintock
2011-09-29 4:21 ` [PATCH 10/16] Fix mdadm for powerpc64 Matthew McClintock
2011-09-29 15:51 ` Richard Purdie
2011-09-29 18:19 ` McClintock Matthew-B29882
2011-09-29 4:21 ` [PATCH 11/16] Fix ghostscript on powerpc64 Matthew McClintock
2011-09-29 4:21 ` [PATCH 12/16] Fix flac build on e500mc cores Matthew McClintock
2011-09-29 15:52 ` Richard Purdie
2011-09-29 18:10 ` McClintock Matthew-B29882
2011-09-29 18:31 ` Richard Purdie
2011-09-29 4:21 ` [PATCH 13/16] Fix HAL on newer kernels without header file Matthew McClintock
2011-09-29 4:21 ` [PATCH 14/16] Add udev patch to compile against newer kernels Matthew McClintock
2011-09-29 4:21 ` [PATCH 15/16] Fix sysklogd build on e500v2 cores Matthew McClintock
2011-09-29 4:21 ` [PATCH 16/16] Add proper deps for nfs-utils, util-linux, and strace Matthew McClintock
2011-09-29 15:55 ` Richard Purdie
2011-09-29 15:47 ` [PATCH 01/16] libnl2: Fix a race on route/pktloc_syntax.h Richard Purdie
2011-09-29 18:28 ` McClintock Matthew-B29882
2011-09-29 18:38 ` Richard Purdie
2011-09-30 17:01 ` Saul Wold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E85F52B.2010000@intel.com \
--to=saul.wold@intel.com \
--cc=B29882@freescale.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox