From: Geoff Levand <geoffrey.levand@am.sony.com>
To: michael@ellerman.id.au
Cc: "Levand, Geoffrey" <Geoffrey.Levand@am.sony.com>,
Segher Boessenkool <segher@kernel.crashing.org>,
Arnd Bergmann <arnd.bergmann@de.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
cbe-oss-dev@ozlabs.org
Subject: Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specificfil es
Date: Tue, 02 May 2006 11:20:20 -0700 [thread overview]
Message-ID: <4457A2E4.8070900@am.sony.com> (raw)
In-Reply-To: <1146528809.27495.21.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Mon, 2006-05-01 at 15:51 -0700, Geoff Levand wrote:
>> Segher, a problem with your suggestion is that our
>> makefiles don't have as rich a set of logical ops as the
>> config files. Its easy to express 'build A if B', but not
>> so easy to do 'build A if not C'. To make this work
>> cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
>> so I can have constructions like this in the makefile:
>>
>> obj-$(CONFIG_PPC_CELL) += ...
>
> Hi Geoff,
>
> I've been ignoring this discussion, but now that I read it I think this
> is all kinda backwards.
>
> PPC_CELL should not denote !SOME_HYPERVISOR, it should just mean "basic
> cell support", ie. PPC_CELL gets you platforms/cell built in.
Yes, that's the way I originally made it, and I switched it back
to that in the latest patch.
> Then we can have SOME_HYPERVISOR which _adds_ support for that
> hypervisor. And PPC_CELL_BLADE which selects things which are actually
> specific to that hardware, like SPIDERNET etc.
> But SOME_HYPERVISOR should not remove support for running on bare metal,
> it should just give you the option of running on the hypervisor. Yes
> that may require testing things at runtime, that's what
> firmware_has_feature() is for.
I feel you're missing one thing though, we need PPC_CELL_NATIVE. We
don't want to build that in if we don't need it. Here's what I setup:
PPC_CELL = make descends into platforms/cell
PPC_CELL_NATIVE = add bare metal support
PPC_IBM_CELL_BLADE = add blade device drivers, etc.
> The goal should be that we have one kernel which can boot on all Cell
> implementations. In fact the ultimate goal is to have one kernel that
> can boot any platform under powerpc, that's a way off still, but we
> don't want to start going backwards.
Yes, that's the whole idea of this patch. It comes from my patch set
'cell: support multi-platform image'... But we also need to be able
to build in only the support needed. This is an important requirement
for consumer products, to reduce the image size.
In a certain class of products the kernel image and read-only parts
of the file system are stored on flash. A smaller kernel means more
space for applications. Also, a smaller kernel image loads faster.
Device startup time is very important for many consumer products.
-Geoff
next prev parent reply other threads:[~2006-05-02 18:20 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-29 23:28 [PATCH 00/13] Cell patches for 2.6.18 Arnd Bergmann
2006-04-29 23:28 ` [PATCH 01/13] cell: always build spu base into the kernel Arnd Bergmann
2006-04-29 23:28 ` [PATCH 02/13] spufs: restore mapping of mssync register Arnd Bergmann
2006-04-29 23:28 ` [PATCH 03/13] cell: fix interrupt priority handling Arnd Bergmann
2006-04-29 23:28 ` [PATCH 04/13] cell: remove broken __setup_cpu_be function Arnd Bergmann
2006-05-05 6:03 ` Paul Mackerras
2006-05-06 0:00 ` Geoff Levand
[not found] ` <C26C730943E01145B4F89E37FE0A022002BBC74B@itdsrvmail02.utep.edu>
2006-05-08 20:03 ` Information for setting up SMT related parameters on linux 2.6.16 on POWER5 Will Schmidt
2006-05-08 23:04 ` Segher Boessenkool
2006-04-29 23:28 ` [PATCH 05/13] cell: enable CPU_FTR_CI_LARGE_PAGE Arnd Bergmann
2006-04-29 23:28 ` [PATCH 06/13] powerpc: fix 64k pages on non-hypervisor Arnd Bergmann
2006-04-29 23:28 ` [PATCH 07/13] powerpc: export symbols for page size selection Arnd Bergmann
2006-05-05 5:56 ` Paul Mackerras
2006-05-05 9:12 ` Arnd Bergmann
2006-04-29 23:28 ` [PATCH 08/13] spufs: set up correct SLB entries for 64k pages Arnd Bergmann
2006-04-29 23:28 ` [PATCH 09/13] spufs: add a phys-id attribute to each SPU context Arnd Bergmann
2006-04-29 23:28 ` [PATCH 11/13] cell: split out board specific files Arnd Bergmann
2006-04-30 2:52 ` Segher Boessenkool
2006-05-01 22:51 ` Geoff Levand
2006-05-01 23:09 ` Segher Boessenkool
2006-05-01 23:49 ` [Cbe-oss-dev] " Arnd Bergmann
2006-05-01 23:50 ` Arnd Bergmann
2006-05-02 0:06 ` Segher Boessenkool
2006-05-02 10:59 ` Arnd Bergmann
2006-05-02 23:38 ` Segher Boessenkool
2006-05-03 0:18 ` Arnd Bergmann
2006-05-03 2:46 ` Paul Mackerras
2006-05-03 6:28 ` Segher Boessenkool
2006-05-04 2:03 ` Benjamin Herrenschmidt
2006-05-02 18:20 ` Geoff Levand
2006-05-02 18:30 ` Arnd Bergmann
2006-05-02 0:13 ` Michael Ellerman
2006-05-02 18:20 ` Geoff Levand [this message]
2006-05-02 13:45 ` Christoph Hellwig
2006-04-29 23:28 ` [PATCH 12/13] cell: abstract priviledge-1 SPU registers for hypervisors Arnd Bergmann
2006-04-29 23:28 ` [PATCH 13/13] cell: set SPU interrupt affinity in spu_priv1 code Arnd Bergmann
2006-04-29 23:42 ` [PATCH 10/13] cell: correctly detect systemsim host Arnd Bergmann
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=4457A2E4.8070900@am.sony.com \
--to=geoffrey.levand@am.sony.com \
--cc=arnd.bergmann@de.ibm.com \
--cc=arnd@arndb.de \
--cc=cbe-oss-dev@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
--cc=segher@kernel.crashing.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