Message-ID: <40045AC7.2070300@mvista.com>
Date: Tue, 13 Jan 2004 12:53:27 -0800
From: George Anzinger <george@mvista.com>
Organization: MontaVista Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
MIME-Version: 1.0
To: Matt Mackall <mpm@selenic.com>
CC: Pavel Machek <pavel@ucw.cz>, kernel list <linux-kernel@vger.kernel.org>,
       Andrew Morton <akpm@zip.com.au>,
       "Amit S. Kale" <amitkale@emsyssoft.com>
Subject: Re: kgdb cleanups
References: <20040109183826.GA795@elf.ucw.cz> <3FFF2304.8000403@mvista.com> <20040110044722.GY18208@waste.org> <3FFFB3D6.1050505@mvista.com> <20040110175607.GH18208@waste.org> <400233A5.8080505@mvista.com> <20040112064923.GX18208@waste.org>
In-Reply-To: <20040112064923.GX18208@waste.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3853
Lines: 96

Matt Mackall wrote:
> 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.).
> 
I am thinking of something more like what was done with the x86 timer code. 
Each timer option sets up a structure with an array of pointers to each option.
There it is done at compile time, and the runtime code tries each.  There it is 
done in order, but here we want to do it a bit differently.

Maybe we could have an "available" flag or just assume that the address being 
!=0 for getdebugchar means it is "available".  I think there should be a 
prefered intface set at config time.  Possibly over ride this with the command 
line.  Then have a back up order in case kgdb wants to communicate prior to the 
prefered one being available.

We would also have a rule that the command line over ride only works if 
communication has not yet been established.  Here, we would also like control 
from gdb/kgdb so we could switch to a different interface, but under gdb control 
at this point.  Either a maintaince command or setting the "channel" with a 
memory modify command.  We would want this to take effect only after the current 
command is acknowledged.
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/