[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080212164244.GA24207@elte.hu>
Date: Tue, 12 Feb 2008 17:42:44 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
"Frank Ch. Eigler" <fche@...hat.com>,
Roland McGrath <roland@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] kgdb-light -v10
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> > Yes and the session has no fixed time limit.
>
> Quite frankly, if kgdb starts doing somethign "fancy", there is no way
> I'll merge it.
>
> This includes things like having "breakpoint reservations" (discussed
> earlier) and just generally trying to add lots of infrastructure to
> make kgdb "fit in" to the kernel.
yes - i zapped hw breakpoint support in -v10 already.
> In other words: I think the kgdb patches have become a lot more
> palatable over the last week, but I think so exactly because they have
> gotten smaller and less invasive. Anything that evokes any discussion
> AT ALL should just be removed. It really should be that simple.
yes, that's what i've been doing. When anything became questionable even
just a little bit, it was the axe or i changed it to something really
obvious and correct.
by 2.6.26 kgdb-light will become so neutral to the rest of the kernel
that we wont even notice that we've merged it ;-)
> [ The exception being that I think hw breakpoint support should be
> added back in - never mind that it won't work if the "native kernel"
> also uses them. Tough.
yeah. I believe we need to achieve a "known zero impact, 100% trustable"
state for KGDB to start with, and add stuff carefully to it.
> So keep the damn thing really simple, and don't try to handle every
> possible thing. We expect the debugger side to have a person with some
> flexibility on it.
yes - if something locks up, it will be the NMI watchdog starting the
debugger eventually - not the other way around. The NMI watchdog is
already system policy which can be turned on/off and is well known and
expresses the user's wishes with what should happen to the system.
The debugger should really be a fundamentally very passive "console"
type of thing, with as little direct policy as possible. That minimizes
the chance that it accidentally messes up something and also makes it
more likely that it will actually work reliably and dependably.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists