lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git pull] kgdb-light -v10
On Tue, Feb 12, 2008 at 01:38:39PM +0100, Ingo Molnar wrote:
> So unless i forgot about something (please yell if so), it seems to me
> kgdb is now pretty ready for an upstream merge.

I don't know -- I have not reread everything. Please don't consider
my comments as approval of the code base. I still think it does quite
a lot of dubious and ugly things overall and should get far more clean up
and get more testing too.

> do spinning for now: we dont _ever_ want to break a correctly working
> system with kgdb.

Stopping all CPUs for indefinite time very much seems like
"breaking a correctly working system" to me. In a correctly working system
kgdb is never entered.

> A valid counter-argument is _not_ to argue "but it would be nice to have
> if the system is broken in X, Y and Z ways" (like you did), but to point
> it out why the behavior we chose is wrong on a correctly working system.
>
> Yes, a buggy system might misbehave in various ways but my primary
> interest is in keeping correctly working systems correct.

The only way I know of to do that is gdb vmlinux /proc/kcore
kgdb certainly isn't it.

> And note that kgdb is not just a "debugger", it's a system inspection
> tool. An intelligent, human-controlled printk.

For that gdb vmlinux /proc/kcore already works fine. Or fireproxy.
If that was the only goal we wouldn't need all that stub code.


> > > just introduce unnecessary complexity.
> >
> > The question is less about actually having it as a module, but just if
> > the interfaces are clean enough to allow it as a module. If not you
> > should probably clean them up.
>
> but your contention is simply wrong. Most of our debugging
> infrastructure is non-modular for a good reason. Modularization
> increases complexity and that's exactly the wrong direction for

The main complexity in module handling is handling (or rather preventing)
module unload. I explicitely excluded that in my earlier mail.
Module loading on the other hand tends to be relatively easy.

I did a modular kernel debugger on my own some time ago and once
the interfaces were clean it was very simple. I think the reverse
is true too -- if having it as a module is easy then the interfaces
are clean too. That is why I asked for it. It's a good basic
sanity check on the design.

>
> > > no, not all architectures have it. This is a weak alias that is
> > > otherwise not linked into the kernel.
> >
> > Can't be very many because oprofile needs it and it works on most
> > archs now. Anyways, the right thing is to just add it to the
> > architectures that still miss it, not reimplement it in kgdb.
>
> it's not reimplemented - kgdb_arch_pc() does not directly map to
> instruction_pointer().

If that is true then it is definitely misnamed and likely
incorrectly implemented on the architecture in question.

> > [...] If kgdb is active it should have priority over crash dumps.
>
> that's the approach we are taking: be as unintrusive as possible. This
> means that the notifier here is registered at the lowest priority. You
> might disagree with it but it's a completely sensible and consistent
> approach.

Yeah, it is consistently wrong agreed.

-Andi



\
 
 \ /
  Last update: 2008-02-12 14:17    [W:0.079 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site