From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: McClintock Matthew-B29882 <B29882@freescale.com>,
Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH v2 10/16] Fix mdadm for powerpc64
Date: Wed, 05 Oct 2011 18:00:11 +0100 [thread overview]
Message-ID: <1317834019.6398.18.camel@ted> (raw)
In-Reply-To: <CAEsOVNeR+DL15jM9TBc9mZkBe4uhD3xJvt=5jrqss+t+k9R-Bg@mail.gmail.com>
On Wed, 2011-10-05 at 16:53 +0000, McClintock Matthew-B29882 wrote:
> On Wed, Oct 5, 2011 at 6:34 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > I dug into this a bit. To quote asm/types.h:
> >
> > /*
> > * This is here because we used to use l64 for 64bit powerpc
> > * and we don't want to impact user mode with our change to ll64
> > * in the kernel.
> > */
> > #if defined(__powerpc64__) && !defined(__KERNEL__)
> > # include <asm-generic/int-l64.h>
> > #else
> > # include <asm-generic/int-ll64.h>
> > #endif
> >
> > So ppc64 kernel space uses ll64 and userspace uses l64.
> >
> > This means __u64 is a long for ppc64 but a long long for x86_64. The
> > format errors occurs rightly because a ull is being printed from a ul
> > variable. This will happen to work but its messy.
>
> Sorry, I'm missing if you are suggesting a solution here... do I need
> to take an alternate approach? The alternative is to patch the
> printfs?
That is the alternative that could probably make it upstream.
I did this mainly to understand what the difference between x86_64 and
ppc64 was so in future I can better spot problem areas and perhaps
others can too.
I'll take the patch but I'd like to include more information about the
reason for the problem in the commit message and strongly hint that it
would be great to get these issues fixed upstream, properly.
Cheers,
Richard
next prev parent reply other threads:[~2011-10-05 17:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 18:52 [PATCH v2 10/16] Fix mdadm for powerpc64 Matthew McClintock
2011-09-30 11:38 ` Richard Purdie
2011-09-30 15:51 ` McClintock Matthew-B29882
2011-09-30 16:29 ` Richard Purdie
2011-10-03 19:22 ` Khem Raj
2011-10-03 21:14 ` McClintock Matthew-B29882
2011-10-03 21:17 ` Khem Raj
2011-10-04 21:52 ` McClintock Matthew-B29882
2011-10-05 11:34 ` Richard Purdie
2011-10-05 16:53 ` McClintock Matthew-B29882
2011-10-05 17:00 ` Richard Purdie [this message]
2011-10-05 19:21 ` Khem Raj
2011-10-05 21:15 ` McClintock Matthew-B29882
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=1317834019.6398.18.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--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