Re: GDB-Protocol: QBaud=<rate> set the baud rate of the remote target

[Stan Shebs <shebs@cygnus.com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 22 Jun 1999 12:14:42 -0700

   >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
   Andrew> This packet replaces the unofficial ``b<hex-rate>'' packet.
   Andrew> The format is:
   Andrew>
   Andrew> 	<- QBaud=<rate>
   Andrew>		-> OK
   Andrew>
   Andrew> 	<-> both local/remote change their baud rate
   Andrew>
   Andrew> <rate> is in decimal.  I _can't_ see a reason for encoding the
   Andrew> value in hex.  In addition, GDB's ``set remotebaud'' command
   Andrew> in conjunction with an additional target-vector are reserved
   Andrew> for this.

   I think it is a very, very, very bad thing to add commands to the
   protocol that change the state of the transport layer.  There are a
   near infinate number of transports that could be used to tunnel the
   remote protocol where "baud" has no meaning.  Likewise, there are a
   huge number of parameters available to tweak those transports that
   make no sense for serial.

I tend to agree with this; I've always been a little uncomfortable
about this packet, and wondered how anybody expected it to work.  I
think that the practical problems of changing the baud rate on the fly
stem from the basic confusion of having commands affect the wrong
layers.

If people really wanted to add something like this, and get it working
for the first time, they ought to modify ser-unix.c to send some kind
of out-of-band message to a specially-setup stub and have the switch
happen "in between" packets, so that from remote protocol's point of
view, nothing actually happened.

								Stan