Re: kgdb cleanups

[Matt Mackall <mpm@selenic.com>]

On Sun, Jan 11, 2004 at 09:41:57PM -0800, George Anzinger wrote:
> For the internal kgdb stuff I have created kdgb_local.h which I intended to 
> be local to the workings of kgdb and not to contain anything a user would 
> need.

Agreed, I just haven't touched it since you last mentioned it.

> >+struct kgdb_hook {
> >+	char *sendbuf;
> >+	int maxsend;
> 
> I don't see the need of maxsend, or sendbuff, for that matter, as kgdb uses 
> it now (for the eth code) it is redundant, in that the eth putchar also 
> does the same thing as is being done in the kgdb_stub.c code.  I think this 
> should be removed from the stub and the limit in the ethcode relied upon.

Fair enough.

> > void
> > putDebugChar(int c)
> > {
> >-	if (!kgdboe) {
> >-		tty_putDebugChar(c);
> >-	} else {
> >-		eth_putDebugChar(c);
> >-	}
> >+	if (kh)
> >+		kh->putchar(c);
> > }
> 
> I was thinking that this might read something like:
>          if (xxx[kh].putchar(c))
>                 xxx[kh].putchar(c);
> 
> One might further want to do something like:
>          if (!xxx[kh].putchar(c))
>                 kh = 0;
> 
> In otherwords, an array (xxx must, of course, be renamed) of stuct 
> kgdb_hook (which name should also be changed to relate to I/O, 
> kgdb_IO_hook, for example). Then reserve entry 0 for the rs232 I/O code.  

Dunno about that. Probably should work more like the console code,
whoever registers first wins. Early boot will probably be the
exclusive province of serial for a while yet, but designing it in is
probably short-sighted.

>  An alternate possibility is an array of pointer to struct kgdb_hook which 
> allows one to define the struct contents as below and to build the array, 
> all at compile/link time.  A legal entry MUST define get and put, but why 
> not define them all, using dummy functions for the ones that make no sense 
> in a particular interface.

Throwing all the stubs in a special section could work well too. Then
we could add an avail() function so that early boot debugging could
discover if each one was available. The serial code could use this to
kickstart itself while the eth code could test a local initialized
flag and say "not a chance". Which gives us all the architecture to
throw in other trivial interfaces (parallel, bus-snoopers, etc.).

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting