Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: The case for a standard kernel debugger | Date | Thu, 14 Sep 2000 14:21:44 +0200 |
| |
Marco Colombo wrote: > BTW, a kernel debugger *is* available. And maybe even a more powerful > one will be if Jeff decides to port and publicly release it.
One that subject, I would *love* to take the time to see how small a subset of Ext2 I could write to have a (mostly) non-invasive source code display.
- No write, no truncate, no remove (i.e., no balloc, no ialloc, etc.) - No buffering - No superblock read: block size always 4K - No descriptors, assume inode table blocks always in usual place - No dcache: write a simplified directory to a known inode - No options
The hardest problem: how do you do the block read? Possibilities:
- Ignore the problem, use normal block device I/O - Use the real mode bios, needs V86 support - Low level scsi ops with some pre-debugging setup - Use a minimal subset of IDE - Hacked up protocol over serial port - Likewise over ethernet
Doubtless there are many other ways to do it with varying degrees of difficulty, intrusiveness, performance and system-dependence. Of these techniques the one I personally know best is the V86 approach, having written a Dos extender in the distant past. It wouldn't be as hard as a Dos extender but it would still take some effort. I'd guess that the minimal IDE subset would be a better approach though, because you can ignore all mode switching crap, be able to re-purpose a lot of existing source and end up with a more generic result.
No matter how you do it there will some impact on system behavior somewhere. There always is with any debugger and this has never stopped people from using them. First, you start with a horribly intrusive debugger then you gradually make it better.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |