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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:23 EST