RFA: patch to remote.c for larger download packet support (part 1)

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> >>>>> "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?

Even with such a mechanism I think that there would still need to be a
way of allowing the user to force the packet size.

A negotiation feature could be introduced as part of a later round of
changes.

	Andrew

> 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?)