lkml.org 
[lkml]   [2009]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:core/debug] debug lockups: Improve lockup detection
On Sun, 2 Aug 2009 22:41:50 +0200 Ingo Molnar <mingo@elte.hu> wrote:

>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Sun, 2 Aug 2009 21:26:57 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > > > I think this just broke all non-x86 non-sparc SMP architectures.
> > >
> > > Yeah - it 'broke' them in the sense of them not having a working
> > > trigger_all_cpu_backtrace() implementation to begin with.
> >
> > c'mon. It broke them in the sense that sysrq-l went from "works"
> > to "doesn't work".
>
> You are right (i broke it with my patch) but the thing is, sysrq-l
> almost useless currently: it uses schedule_work() which assumes a
> mostly working system with full irqs and scheduling working fine.
> Now, i dont need sysrq-l on mostly working systems.
>
> So the 'breakage' is of something that was largely useless: and now
> you put the onus of implementing it for _all_ architectures (which i
> dont use) on me?

I never said that.

It's appropriate that those architectures be left with their existing
level of functionality/usefulness, as you're already discussing.

> > It's better to break the build or to emit warnings than to
> > silently and secretly break their stuff.
>
> But that warning will bounce the ball back to me, wont it? My patch
> will be blamed for 'breaking' those architectures, right?

It's a very crude and somewhat rude way of communicating information to
other architecture maintainers.

A better way would be to send them an email explaining the problem and
outlining some solutions, no?


\
 
 \ /
  Last update: 2009-08-02 23:11    [W:0.056 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site