Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specificfil es

[Geoff Levand <geoffrey.levand@am.sony.com>]

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/