Re: kgdb cleanups

[George Anzinger]

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@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/