Re: [PATCH] mt set per-command remote-packets on|off

[Yao Qi <yao@codesourcery.com>]

On 12/11/2013 05:12 AM, Doug Evans wrote:
> 
> 
> Good point.  OTOH going that route brings more complication that isn't
> needed at the moment (rsp perf data*is*  needed now).
> [I finally have some(!) time to return to this.]

That is good! :)

> 
> 
>> >
>> >IWBN to add a new interface target_print_statistics, and leave each target to decide what data to print.
> 
>  From a high level perspective the target collects the statistics, but
> consumers will want to print them their own way.
> I didn't want to go "whole hog" yet because it's not clear yet what
> the different consumers are.
> [And remote protocol performance is in real need of improvement so I
> wanted to start solving that problem now.]
> 

That is OK to me.  I am eager to see collect rsp perf data through
this and potential improvement, rather than designing an ideal
interface.

> 
>> >
>> >
>> >
>>> >>diff --git a/gdb/remote.c b/gdb/remote.c
>>> >>index 186c058..429a49c 100644
>>> >>--- a/gdb/remote.c
>>> >>+++ b/gdb/remote.c
>>> >>@@ -426,6 +426,14 @@ struct remote_state
>>> >>
>>> >>     /* The state of remote notification.  */
>>> >>     struct remote_notif_state *notif_state;
>>> >>+
>>> >>+  /* Statistics for measuring protocol efficiency.
>>> >>+     Note: These record data at the protocol level, so to speak.
>>> >>+     If we're communicating over a flaky channel and have to resent packets
>>> >>+     that is not accounted for here.  It's recommended to track resends, etc.
>>> >>+     separately.  */
>>> >>+  long packets_sent, packets_received;
>>> >>+  long bytes_sent, bytes_received;
>> >
>> >
>> >Use "unsigned long"?
> 
> How about int?
>

If you prefer signed type here, "long" is fine.

>>> >>
>>> >>+/* Fetch the current packet statistics.  */
>>> >>+
>>> >>+void
>>> >>+get_remote_packet_stats (long *packets_sent, long *packets_received,
>>> >>+                        long *bytes_sent, long *bytes_received)
>>> >>+{
>> >
>> >
>> >... In this way, the number of arguments of function can be reduced.
> 
> It was done this way to separate the collector of the data from the
> printer of the data.
> If we later collect finer grained stats, callers that want a gross
> number can still call this, and this function could sum up the pieces.
> 

Even we just count these four, it is better to put them in a
structure, and associate the structure instance with remote_state.

-- 
Yao (齐尧)