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 --
| Andy Whitcroft | clam |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| David Miller | Re: Slow DOWN, please!!! |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Lennert Buytenhek | [PATCH 08/39] mv643xx_eth: nuke port status register bit defines |
| Jarek Poplawski | Re: HTB accuracy for high speed |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
