This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>>>>> "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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]