On Sat, 2007-04-21 at 11:48 +0200, Andi Kleen wrote: > > Lots of people want kgdb. One person is famously less keen on it, but > > we'll be able to talk him around, as long as the patches aren't daft. > > The big question is if the kgdb developers seriously want mainline. > At least in the past this definitely wasn't the case. I haven't seen any email from kgdb developers saying they didn't want kgdb to be part of mainline. Happen to have any e-mail demonstrating that? It's appears to me that: 1. Jason Wessel is putting a lot of effort at that right now. 2. Tom Rini worked hard at this just a few months ago. 3. George Anzinger was working hard at this a year or two with the mm series and as likely disappointed when it wasn't put into the mainline. As I recall the reason Linus gave was that there were two competing patches and he wanted that be resolved before integrating it into the mainline. So George worked with Amit at SourceForge over that past year or two and it's now integrated. > > If they're not open to change requests from mainline reviewers we don't > even need to bother to start the whole exercise. What issue are there of have been that your referring to? Once KGDB is part of KORG can't it's maintenance and support be a kernel wide responsibility. If someone breaks kgdb shouldn't that be backed out until the KORG developers fixes the problem? Centralizing the responsibility for KGDB seems like mistake. I doubt the FreeBSD folks rip out the KGDB support of a kernel hacker breaks KGDB and then leaves a group of KGDB developers to sort out the problem. Seems it should be cough as a mm patch with Andrew tossing out the patch if it breaks KGDB. Kgdb developers could try to give Andrew a heads up if this occurs and he didn't notice it. Once KGDB is integrated the maintenance should be minimal and changes that break KGDB are likely best addressed by the developer that just broke it. At least that what I'd think is an optimal approach. Perhaps Dave O'Brien could tell us how the FreeBSD folks take care for KGDB. > > Just putting their stuff onto korg isn't enough. Yep, and once it's integrated into korg it should finally become a permanent part of the kernel and I suspect maintained by all kernel developers. New KGDB features could be developed at SourceForge but maintaining kernel coherence seems like a global responsibility. Like running fault injection on your code before checking it in. Maybe I'm totally out to lunch on this; perhaps Dave O'Brien can straighten me our if I'm wrong or the Linux kernel core responsibility paradigm are incompatible with this. I'd prefer Linux being just as good as NetBSD with Debugging support; current presentations like: http://foss.in/2005/slides/netbsd-linux.pdf show our current support as being much worse. Let's fix it. You developed a kgdb proxy for Keith Owens kdb and I suspect you would like to have KGDB being part of the kernel mainline as long as it's done well. I doubt anyone would argue with that. Perhaps it's possible to eventually setup KGDB so it can be debugged with kdb. Once KGDB is mainline that are plenty of issues that can be addressed; for example taking a kernel core dump after dropping into kgdb and having the registers show up correctly in Dave Anderson's crash utility. -piet > > -Andi -- Piet Delaney Phone: (408) 200-5256 Blue Lane Technologies Fax: (408) 200-5299 10450 Bubb Rd. Cupertino, Ca. 95014 Email: [email protected]
Attachment:
signature.asc
Description: This is a digitally signed message part
- References:
- Re: Permanent Kgdb integration into the kernel - lets get with it.
- From: Piet Delaney <[email protected]>
- Re: Permanent Kgdb integration into the kernel - lets get with it.
- From: Andrew Morton <[email protected]>
- Re: Permanent Kgdb integration into the kernel - lets get with it.
- From: Andi Kleen <[email protected]>
- Re: Permanent Kgdb integration into the kernel - lets get with it.
- Prev by Date: Re: [REPORT] cfs-v4 vs sd-0.44
- Next by Date: Re: BUG: Null pointer dereference in fs/open.c
- Previous by thread: Re: Permanent Kgdb integration into the kernel - lets get with it.
- Next by thread: [PATCH] sysctl_panic_on_oom broken
- Index(es):