Andrew Morton wrote:I can also underline this - and add the aspect that a kernel debugger may also nicely serve to explore tricky code paths interactively. This specifically can lower the entrance barrier to complex kernel subsystems for new developers/bug hunters. With the latest changes, now all available through Jason's git repos for 2.6.25, kgdb should be usable again ("Now even more stable than ever!" ;) ). It became much less invasive towards critical code paths during recent rounds of refactoring, so we can hopefully meet the requirements for merging it upstream soon (2.6.26?). While too many people consider a debugger as _the_ tool for kernel development, which it clearly isn't, it remains a fairly useful feature, and I don't see any regression, technically or organizationally, it may introduce to Linux. IMHO, it would be a pity if kgdb have to remain out off tree and may potentially fall back at quality levels that many of us had fought with in the past. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 33/37] dccp: Initialisation framework for feature negotiation |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
