Andi Kleen wrote:
quoted text
>> kgdb? Not so interesting. We have many more hard problems happening at 
>> user sites, not in developer hands.
> 
> The other problem with the current kgdb code is that it has some serious
> problems. e.g. it reinvents various kernel interfaces that already
> exist -- one example is that it adds new notify_die()s just to reimplement
> the standard __ex_table exceptions in a bogus way.

/me was once wondering as well why kgdb installs a seconds way of
handling (its own) faults. Jason explained to me that this approach is
more robust against corruption along the normal fix-up path. Maybe he
can elaborate better than I why this is useful (or what real-life bug
once encouraged the current design).

quoted text
> Couple of other issues. So even if it was a good idea to merge the
> code is not really fully in merge shape anyways.

If you recall the issues (and they are still present), it would be nice
to have them listed. kgdb suffered a lot from historic cruft, but we
already remove at least some of it over the last patching rounds.
Whatever remains should be addressed ASAP.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/