Andi Kleen wrote: >> 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). > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
