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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
