[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The case for a standard kernel debugger

"TRG hereby offers to SGI Corporation exclusive, unlimimited, perpetual,
transferable, licensee rights to the Linux port of the MANOS debugger
and upon TRG posting this debugger code to the Linux community, agrees
to grant to SGI the rights to maintain and create derivative works from
the MANOS Debugger source code, and the right to place SGI's Copyright
notices on this code. In exchange for these rights, SGI will be
required to accept support costs for maintaining the MANOS debugger, and
will provide Keith Owens or another representative of it's election
reasonable consulting fees for a period of five (5) years to maintain
this source base for the Linux Operating System. TRG reserves all
other rights."

Since SGI has recognized the need for good debugging technology in
Linux, and has shown a willingness to fund something that makes
everyone's life easier, TRG would be willing to contribute to SGI's
demonstrated leadership in this area.

TRG's plans are to focus on MANOS once the Linux merge is completed, and
we will post the MANOS debugger for Linux, but we would really like to
see a commercial company like SGI carry on supporting it on Linux. I
can do some of it, but I think having a "kernel debugger source" for the
industry like SGI who wants to fund and promote kernel debugging tools
would make more sense and as Keith pointed out, centralize changes and


Jeff Merkey

"Jeff V. Merkey" wrote:
> I am porting the MANOS debugger to Linux. No changes here. Linus will
> reject it for the tree, but the offer for SGI and Keith Owens to take it
> over and merge it with his kdb effort is also genuine.
> :-)
> Jeff
> Daniel Phillips wrote:
> >
> > 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
> > Please read the FAQ at
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.042 / U:7.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site