[PATCH] rpaphp broken in ameslab

linas at austin.ibm.com linas at austin.ibm.com
Thu Jul 1 11:20:32 EST 2004


On Thu, Jul 01, 2004 at 09:41:09AM +1000, Paul Mackerras wrote:
>
> patches suitable for forwarding to Andrew Morton, complete with
> rationale and explanation.  (Which you have been doing - thanks.)

OK, well, except that, until yesterday, I haven't been :) there's
a few months of accumulated patches lying around.  They're mostly
trite.

> 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.

OK.  The short answer for eeh.c is 'all of it'.

> 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?

I duuno... I thought this was standard operating proceedure ...
one can get cc'ed on all bugzilla ppc64 activity automatically.
Whenever a bug gets marked 'fixed-awaiting-test' one can grab
the patch and go with it.  That's what SUSE does.

I do have one big concern with tracking patches by email vs.
tracking patches in bugzilla, and that is the problem of closure.
I sent four patches yesterday, heard responses for two of them.
What about the other two? Were they applied? Rejected? Still
in the queue? Accidenetally ignored & forgotten?    How will
I know?  In bugzilla, theres a very clear idea of what the
status is, and there's a 'paper trail' to go with it.
Its got built-in nagging ... I can say things like 'please
apply patch 7538, its been ready for months', which works out
a lot better than 'hey remember that email I send you months
ago, did you ever get around to it?'

Problem with un-adorned email is you never know if a thread
came to a conclusion or not.  But bugzilla has a built-in
status tracker.. you know when the thread is dead.

I like to think of bugzilla as 'plain-email with extra status
bits' -- its auto-threaded, everyone can review a thread at
any time, every post to every thread is there, even for
late-comers who might not have been 'subscribed' at the begining.
And you can perform complex queries accoss threads and topics,
which is something mutt doesn't do, and I don't think pine,
elm, evolution or any of the other emailers do either.

What would really be slick is if there was a button on
bugzilla, that, when clicked, did a 'bk push'.

> 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.

OK, we have that code already; presently, its not compiled with
rpaphp_pci.c, its compiled with eeh.c.  I can cut and paste it
into drivers/pci/hotplug/rpaphp_pci.c and/or create a new file
drivers/pci/hotplug/rpaphp_eeh.c  That eleminates the need for
the callback.

--linas

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





More information about the Linuxppc64-dev mailing list