[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