Thread (18 messages) read the whole thread 18 messages, 9 authors, 2005-01-23

Re: [PATCH] raid6: altivec support

From: Sven Luther <hidden>
Date: 2005-01-23 11:18:37
Also in: lkml

On Thu, Jan 20, 2005 at 10:22:18AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2005-01-19 at 07:43 +0000, David Woodhouse wrote:
quoted
On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
quoted
We should probably "backport" that simplification to ppc32...
Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
like mips/parisc/s390. Or would that get vetoed on the basis that we
don't have all that horrid non-OF platform support in ppc64 yet, and
we're still kidding ourselves that all those embedded vendors will
either not notice ppc64 or will use OF?
Oh well... i've though about it too, and decided that I was not ready to
try it. For one, the problem you mention, with the pile of embedded
junk. I made the design decision to define an OF client interface as the
standard & mandatory entry mecanism to the ppc64 kernel (except legacy
iSeries of course, but I don't want that to multiply). That or the
kexec-like entrypoint passing a flattened device-tree in.

Also, there are other significant differences in other areas. At this
point, I think the differences are  bigger than the common code.

What would be interesting would be to proceed incrementally, having a
directory somewhere to put the "common" ppc/ppc64 code, and slowly
moving things there.
It may be too complicated, but what about letting the commong code in ppc, and
moving the ppc32 code into ppc32 ? 

Friendly,

Sven Luther
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help