Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: siteinfo split between powerpc-common & powerpc-linux
Date: Thu, 21 Jul 2011 11:24:36 -0700	[thread overview]
Message-ID: <4E286EE4.3020502@mentor.com> (raw)
In-Reply-To: <CAMKF1spLfWX4ANoyAjzypTHpwBUJjOhRKT4Asg22=qw1qPcHQA@mail.gmail.com>

On 07/21/2011 11:20 AM, Khem Raj wrote:
> On Thu, Jul 21, 2011 at 10:05 AM, Tom Rini <tom_rini@mentor.com> wrote:
>> On 07/21/2011 09:48 AM, Khem Raj wrote:
>>> On Thu, Jul 21, 2011 at 5:17 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>> Why do we have a split between powerpc-common & powerpc-linux?
>>>>
>>>> I assume powerpc-linux is used and picked up for powerpc-linux-uclibc in addition to normal powerpc-linux.
>>>>
>>>> I'm looking at adding powerpc64 support and powerpc-common is all kinda of broken for it.  I'd like to just merge powerpc-common & powerpc-linux (as powerpc-linux 32-bit) for now and start a new powerpc-common that refactors 32/64 commonalities.
>>>>
>>>> Unless someone says otherwise about the meaning of these files.
>>>
>>> powerpc-common is shared between uclibc and eglibc at present and may
>>> be shared with other OSes that may build with OE in future.
>>> traditionally powerpc-common implicitly implied 32bit so I am not
>>> surprised if its broken for ppc64. You could add powerpc64-common
>>> and leave 32bit alone. See how its done for mips64 in oe.dev
>>>
>>> http://git.openembedded.org/cgit.cgi/openembedded/tree/site
>>
>> I'd argue that what we do for mips today is also wrong and I'm going to
>> try and fix it as soon as I can.  In these cases we should have:
>> common, common-linux, common-$libc, mips-common, mips-linux,
>> mips64-linux and if needed mips64-linux-libc.
> 
> yes that structure would be desirable. It would need a bit of overhaul
> and lot of testing.
> since you have something setup for your import from oe stuff for same.
> may be you can take a stab at it

Yeah, it's on my list now that the first step is really in :)  I hope to
get the obvious bits rebased and tested and posted today at least, and
then get to finishing the obvious bits and start trying the less obvious
ones.  Glad you fixed uclibc, btw, that had me scratching my head on a
few things we do today :)

-- 
Tom Rini
Mentor Graphics Corporation



  reply	other threads:[~2011-07-21 18:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-21 12:17 siteinfo split between powerpc-common & powerpc-linux Kumar Gala
2011-07-21 12:31 ` Leon Woestenberg
2011-07-21 16:48 ` Khem Raj
2011-07-21 17:05   ` Tom Rini
2011-07-21 18:20     ` Khem Raj
2011-07-21 18:24       ` Tom Rini [this message]
2011-07-21 22:30         ` Kumar Gala

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=4E286EE4.3020502@mentor.com \
    --to=tom_rini@mentor.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