[RFC] splitting out LPAR support from CONFIG_PSERIES

[Olof Johansson]

On Tue, Feb 22, 2005 at 05:23:51PM +0100, Arnd Bergmann wrote:
> I have a private patch set that currently depends on this patch.
> It introduces a new compile time option that makes it possible
> to disable support for LPAR or native setups from a pSeries kernel.
> 
> Obviously, this is not for generic distribution kernels, but I think
> it makes sense to have the option when you're building for just one
> machine. It also makes some of my subsequent patches simpler, especially
> enabling RTAS on non-pSeries machines without requiring LPAR support.

I don't see how the RTAS-on-other-platforms could be impacted
significantly by this? Even if you can't share the code at this time,
could you describe what it enables you to do that you can't with the
LPAR code there?

> The current form of the patch introduces lots of new #ifdefs, which
> can be reduced if we use the scheme I proposed in the 
> 'Introduce CPU_HAS_FEATURE() macro' discussion. It would also be
> cleaner to split the pSeries_iommu code into LPAR and native files.

I agree that maybe the iommu code should be split, but it's not a huge
file as-is so it wasn't a priority during any of the rewrites so far.

The added feature macros were technically neat, but I didn't like the
implementation as it was presented, it's too easy to get it wrong
when using the macros. Maybe they could be done in a cleaner way
somehow. Anyway, that's a different discussion.

> I'm not proposing inclusion of this patch at this point, but I'd like
> to know if the idea is ok or if I should better try not to touch
> the pSeries code.

I think it's a bad idea, but I don't have any real strong motivations
for it: Mainly the fact that right now a pSeries kernel will boot
anywhere, keeping some of the rope away from users to hang themselves
with by building specialized kernels. We've been working in the other
direction lately, with PPC_MULTIPLATFORM booting both powermac and
pseries/openpower machines.

There's also the ambiguity of what machines require LPAR-enabled
kernels. Currently any POWER5 machine would do, even HMC-less setups,
while a HMC-less POWER4 setup runs a native kernel. JS20 has a thin
firmware layer that emulates an LPAR environment too, which might not
be obvious to everyone. Of the pSeries machines, only POWER3 and POWER4
SMP could run a non-LPAR kernel. There's just too much room for
confusion.

Bottom line is, besides for embedded setups where every byte counts,
I'm not sure it's worth it. I can't see right now how it'd make the
other patch all that much easier to add. If it does, then maybe it's a
sign we should clean the code in other ways. :-)


-Olof