Packing "R" actions in a QTDP packet

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Packing "R" actions in a QTDP packet

jimb (Bugzilla)
The code in stringify_collection_list will concatenate as many 'M' and
'X' actions as it can in a packet, but it leaves 'R' actions in a
packet by themselves.  Is there any technical reason for this?  Should
I simply document the protocol as allowing actions to be packed
together as much as you like as long as the overall packet size
doesn't get too big, or should I say that 'R' actions require a packet
unto themselves?
Reply | Threaded
Open this post in threaded view
|

Re: Packing "R" actions in a QTDP packet

Michael Snyder
Jim Blandy wrote:
> The code in stringify_collection_list will concatenate as many 'M' and
> 'X' actions as it can in a packet, but it leaves 'R' actions in a
> packet by themselves.

Are you sure?  That's not my recollection, though admittedly
it's been 5 years or so...  In my mental picture, the R bitmask
goes somewhere in the QTDP message, just *before* the memranges.

There is of course only one 'R' <thing> per tracepoint,
because it's a bitmask...

 > Is there any technical reason for this?  Should
> I simply document the protocol as allowing actions to be packed
> together as much as you like as long as the overall packet size
> doesn't get too big, or should I say that 'R' actions require a packet
> unto themselves?

Reply | Threaded
Open this post in threaded view
|

Re: Packing "R" actions in a QTDP packet

jimb (Bugzilla)
On 11/21/05, Michael Snyder <[hidden email]> wrote:
> Jim Blandy wrote:
> > The code in stringify_collection_list will concatenate as many 'M' and
> > 'X' actions as it can in a packet, but it leaves 'R' actions in a
> > packet by themselves.
>
> Are you sure?  That's not my recollection, though admittedly
> it's been 5 years or so...  In my mental picture, the R bitmask
> goes somewhere in the QTDP message, just *before* the memranges.

Well, that's what the code does.  It always does a savestring and
copies tmp_buf to the first entry in str_list, regardless of the size.
 'count', used to track overall packet size in the 'M' and 'X' code,
doesn't even get used in the 'R' code.

> There is of course only one 'R' <thing> per tracepoint,
> because it's a bitmask...

Oops.  That makes sense; I'd better document it.