[remote] Checking for supported packets

[Daniel Jacobowitz <drow@false.org>]

I've been working, for the last couple of months, on a wide variety
of projects that involve new remote protocol packets.  I'm planning
to submit each and every one of them; I've just been busy, and
also some of them aren't quite fully baked yet.

Before I start doing that, though, I'd like to trigger a little
conversation about a topic that's been bothering me.  When we
connect to a target, there's a number of packets that we need
to send right away, to find out if they're supported or to get
information about the target's current state.  Here's a current
sample:

Sending packet: $Hc-1#09...Ack
Packet received:
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S00
Sending packet: $Hg0#df...Ack
Packet received:
Sending packet: $pf#d6...Ack
Packet received: 00000000
Packet p (fetch-register) is supported
Sending packet: $m0,4#fd...Ack
Packet received: 1000ffe7

qC and qOffsets are both probes.  [Hc/Hg we don't even notice that
the target has failed to support, so we keep sending them.  That's
unrelated.]

I've got at least two more packets on my list that would have
to be probed for at connect: one to read available features (the
XML bits on my branch, which are coming along well), and another
very useful probe that asks the target how big of a packet it
can handle.  That's a huge performance help on any link with latency
measurable in respect to its bandwidth; it's especially useful over
TCP, whether to a local system or to one far away.

Every new packet of this type has to be probed for on each new
target connection.  This takes a noticeable amount of time.

So, I'm wondering, can we cut that number down, and should we?
Something like this:

-> qPackets?
<- qPackets,qPacketSize+,qOffsets-,qPart:available+,qC-

"I support the qPacketSize and qPart:available queries, but don't
bother probing for qOffsets or qC, they won't work".

This isn't the most useful as it is.  There's a lot of possible
alternatives, for instance:

  1. If qPackets is not present, assume new packets are not supported;
     i.e. require the stub to respond to qPackets before trying
     qPart:available.

  2. If the qPackets response does not mention a packet, assume it
     is not supported.

  3. Or, if the qPackets response does not mention a packet, probe
     for it.

I'm guessing that the most useful interpretation would be something
like 1 && 2, but I mention 3 because implementing #2 could prove
to be a problem for some designs of remote stub (with separate
halves for the protocol bits and the controlling hardware bits).
Anyone think this is likely to be a problem in practice?  Other
possible approaches?

-- 
Daniel Jacobowitz
CodeSourcery