lkml.org 
[lkml]   [2004]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kgdb cleanups
Amit S. Kale wrote:
> On Wednesday 14 Jan 2004 2:50 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>Regarding pluggable iterfaces -
>>>The version I have lets a user to choose the interface by supplying
>>>appropriate command line. (e.g. kgdbwait kgdb8250=... or kgdbwait
>>>kgdbeth=...) It supports an arbitrary number of interfaces. The kgdb core
>>>itself is independent of an interface. All interfaces are defined by a
>>>structure described below. An interface registers itself with kgdb core
>>>by assigning this structure to pointer kgdb_serial.
>>>
>>>struct kgdb_serial {
>>> int chunksize;
>>
>>Do we really need this? The only place I saw it used it did not seem to
>>matter where the split occured and there was now endchunck/beginchunck
>>stuff. I would MUCH rather see the interface code take care of this with
>>out mucking up the core code (as the eth code already does). Did I miss
>>something here?
>
>
> Having an interface recognize a kgdb core record isn't a good design.
> Having kgdb core record know interface limitations isn't good either.
>
> If kgdb calls flush at end of a packet and an interface splits a packet
> whenever its length goes above its limit, that'll be the right way of doing
> it.

I think this is what happens in the current eth code.

>
>>> int (*read_char)(void);
>>> void (*write_char)(int);
>>> void (*flush)(void);
>>> int (*hook)(void);
>>> void (*begin_session)(void);
>>> void (*end_session)(void);
>>>};
>>>
>>>Where chunksize is maximum chunksize an interface can handle.
>>>
>>>read_char and write_char are derived from getDebugChar and putDebugChar
>>>flush flushes written characters. Flush control is given to kgdb core so
>>>that it can ensure that #checksum doesn't split.
>>
>>Actually, I think it is needed so that gdb knows that the kgdb stub has
>>exited. This could, of course, be done with out the flush, but then the
>>write code would have to recognize an end of record (not hard with the
>>given protocol). I don't think there is any requirement that a checksum
>>not be split. My assumption here is that the logical record is reassembled
>>on the gdb end without concern about how many physical records are
>>involved. Is this not true?
>
>
> I guess yes. Splitting of #checksum may not matter.
>
>
>>>begin_session and end_session inform an interface about a gdb
>>>communication session. (Haven't decided about console packets to gdb yet)
>>
>>I assume you mean entry to the stub/ exit the stub as a "session". This
>>eliminates the old hook, right?
>
>
> Yes. begin_session and end_session mark entry and exit points into
> handle_exception. They are required to mark ethernet interface in trap mode.
>
> What's old hook?

I think it was a function in eth that was called to mark the begin and end just
as begin_session and end_session do. Might want to consider one function for
this, with a parameter.

-g


--
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/

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