[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080806185719.GE24801@one.firstfloor.org>
Date: Wed, 6 Aug 2008 20:57:19 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Jason Wessel <jason.wessel@...driver.com>
Cc: Andi Kleen <andi@...stfloor.org>, jmerkey@...fmountaingroup.com,
Nick Piggin <nickpiggin@...oo.com.au>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Stefan Richter <stefanr@...6.in-berlin.de>,
Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger
> It depends how you look at the problem. I would agree that the use of
Yes I left the possibility of a "someone writing a in kernel kgdb UI"
out. Indeed that would be a possibility.
On the other hand I'm not sure it would save all that much code
versus just directly working on top of die notifiers.
Also the gdb stub interface definitely has its limitations too.
> > be quite possible to have a multitude of debuggers just using
> > them. In fact that's already the cases, kprobes and kgdb and
> > kdump are all kinds of debuggers using such hooks.
> >
>
> I would agree that the possibility exists to use the hooks directly,
It's not just a possibility, they are already used by multiple
debugger like subsystems. e.g. kprobes is certainly a kind of debugger.
-Andi
--
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