[PATCH] rpaphp broken in ameslab

[Paul Mackerras]

Linas,

> You and Anton are responsible for keeping the arch/ppc64 directories
> in sync between sles9, ameslab, and akpm.  You are, after all, the
> one true official, designated maintainer ... if the code hasn't been

Yes, ultimately.

However, that doesn't mean that I am the subject matter expert for all
parts of the arch/ppc64 code.  Just as Linus isn't the expert for all
parts of the entire kernel tree.  In the areas where I am not the
expert I need and expect the expert(s) for those areas to be sending
me patches with explanations that I can forward upstream.

It's not good enough for the expert to just put the latest and
greatest code into ameslab.  If I'm not the expert, I don't know,
without going digging into the revision history, what the rationale
for the changes is.  I also don't know whether what is in there is
just what we want or if it is something that we just want a few
developers to try.

Thus, I need the experts in areas such as RAS and EEH to be sending me
patches suitable for forwarding to Andrew Morton, complete with
rationale and explanation.  (Which you have been doing - thanks.)

As for the SLES9 tree, we (Anton, Jeremy Kerr and I) have been
spending some effort on identifying which changes need to go
upstream, and in fact most of them are upstream already.  However, in
areas such as EEH and RAS it can take us considerable effort to work
out why changes are being made and whether they should go upstream,
when the expert in the area could just take one look and say very
quickly yes/no and why.

> >From where I sit, the sles9 code is really the latest, greatest, most
> tested and debugged arch/ppc64 code that there is.  This is the tree
> that the developers get thier code/patches into.  Ameslab is distinctly
> downlevel (for example, sles9-2.6.5-7.79 has an eeh.c that has a number
> of patches, some up to a month old, that haven't yet appeared in ameslab.).

Well... why not?  Why haven't the people who have been debugging EEH
problems in sles9 been at least cc'ing the patches to me?

> If the akpm tree doesn't have eeh_register_disable_func() then its
> badly out of date, since that function got added many moons ago.

I never sent that upstream because (a) the EEH developer(s) never sent
me a proposed patch to go upstream and (b) as I understood it, Greg KH
had vetoed that approach.

> Yes, eeh_register_disable_func() is an ugly hack; its because rpaphp
> can be built as a module, and eeh cannot, yett eeh needs to call into
> rpaphp.

I think we should have a notifier list for EEH events and a way for
code to request to be added to that list.  The rpaphp code can then
be notified about EEH events.  What it does then is up to it.  Having
the EEH code decide that a slot removal is the right thing seems
bogus.  That should be up to the rpaphp code and/or userspace.

Paul.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/