[PATCH V3 1/9] Adapt `info probes' to support printing probes of different types.

[Pedro Alves]

On 11/14/2014 11:08 PM, Sergio Durigan Junior wrote:
> On Friday, November 14 2014, Pedro Alves wrote:
> 
>> On 10/31/2014 06:56 PM, Sergio Durigan Junior wrote:
>>> Also, any particular reason why you did not create a field "type" inside
>>> "struct probe", instead of making a function that returns the string?  I
>>> consider the field would be simpler (i.e., not pollute the probe_ops
>>> structure), and it could be set when creating the probes.
>>
>> Not sure I understood it (and probably doesn't matter much), seems like
>> that'd waste memory storing the same info over and over?
> 
> We would be wasting sizeof (char *) for each probe created, indeed, but
> I think this is clearer (also for debugging purposes) than having all
> the necessary machinery to call a function that will return the same
> info...

IMO, that's not cleaner, because the type name is a property of
the type, not of the instance, so it makes sense to get it from the
type (thus through an ops method).  Writing the equivalent C++ may
make it clearer.  Something like:

struct probe
{
...
   virtual const char *type_name () = 0;
};

struct stap_probe : public probe
{
...
   virtual const char *type_name () { return "stap"; }
};

struct dtrace_probe : public probe
{
...
   virtual const char *type_name () { return "dtrace"; }
};


And then in info_probes_for_ops:

      const char *probe_type = probe->probe->type_name ();

> 
> Anyway, I won't oppose the current approach too, I was just curious :-P.


Thanks,
Pedro Alves