This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: patch to remote.c for larger download packet support (part 1)
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: RFA: patch to remote.c for larger download packet support (part 1)
- From: jtc at redback dot com (J.T. Conklin)
- Date: 06 Oct 1999 10:54:37 -0700
- Cc: "Frank Ch. Eigler" <fche at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- References: <19991005160552.A1007@cygnus.com> <37FA9AD4.C0723926@cygnus.com>
- Reply-To: jtc at redback dot com
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I've the same general concern that J.T. raised. The operation
Andrew> should be more robust and the user problably better informed.
Perhaps we're going about this the wrong way. The target 'knows' the
maximum packet size it can accept. So shouldn't there be a mechanism
to negotiate the MTU between GDB and the target?
I am thinking of something like TCP MSS negotiation, where each side
of the connection tells the other the maximum packet size it is able
to receive.
At present, we assume symmetric packet sizes for transmit and receive
(remote_write_size is used to limit the size read requests as well as
writes). I don't know whether or not it is worthwhile to support
asymmetry.
A possible implementation is a new query 'qMtu' (or qMss, qMru, ...),
where the target responds with the maximum packet size it supports.
If we decide to support asymetric packet sizes, GDB could tell the
target with 'QMtu=XXX'. The drawback is that such negotiation would
increase the time necessary to attach to the target. (Should these
values include the framing overhead? What does that mean if we keep
the existing remote protocol but change the framing scheme?)
--jtc
--
J.T. Conklin
RedBack Networks