This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: GDB-Protocol: QBaud=<rate> set the baud rate of the remote target
- To: Andrew Cagney <ac131313@cygnus.com>
- Subject: Re: GDB-Protocol: QBaud=<rate> set the baud rate of the remote target
- From: jtc@redback.com (J.T. Conklin)
- Date: 22 Jun 1999 12:14:42 -0700
- Cc: gdb@sourceware.cygnus.com
- References: <376EEC27.44BB2FD9@cygnus.com>
- Reply-To: jtc@redback.com
>>>>> "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.
Given the choices of:
1) design and implement a universal transport control protocol
that can extend to cover all posible transports.
2) add transport control commands ad hoc.
3) declare that transport control is beyond the scope of the
remote protocol.
I'll pick 3.
Just in case I haven't convinced anyone, when does the transport layer
state change? When it's received, or after the ACK is transmitted.
In either case, there are problems if the command or the
acknowlegement packet is dropped.
--jtc
--
J.T. Conklin
RedBack Networks