Corey,
Ok, we could get rid of the alias information. I just want to make
sure we have room for extension.
And I agree that alias is not a good term, it is more a variant or derivative
of the original event or unit mask. I will fix that.
On Wed, Dec 16, 2009 at 12:58 AM, Corey Ashford
<cjash...@linux.vnet.ibm.com> wrote:
>
>
> stephane eranian wrote:
>>
>> Corey,
>>
>> We still need to settle on the user interface to extract default
>> information (and maybe aliases information).
>>
>> Here is what I have today:
>>
>> typedef struct {
>> const char *name;
>> const char *desc;
>> const char *alias;
>> pfm_pmu_t pmu;
>> int idx;
>> int nattrs;
>> int size;
>> uint64_t code;
>> struct {
>> int is_alias:1;
>> int reserved:31;
>> };
>> uint64_t reserved[9];
>> } pfm_event_info_t;
>>
>
> You could get rid of is_alias if .alias doubled as a sentinel: alias points
> to an event name string if this event is an alias, and is NULL otherwise.
>
>> typedef struct {
>> const char *name;
>> const char *desc;
>> const char *alias;
>> pfm_attr_t type;
>> struct {
>> int is_dfl:1; /* is default */
>> int is_alias:1;
>> int reserved:30;
>> };
>> int idx;
>> int size;
>> uint64_t code;
>> union {
>> uint64_t dfl_val64;
>> const char *dfl_str;
>> int dfl_bool;
>> int dfl_int;
>> };
>> uint64_t reserved1[6];
>> } pfm_event_attr_info_t;
>>
>> int pfm_get_event_info(int idx, pfm_event_info_t *info);
>> int pfm_get_event_attr_info(int idx, int attr_idx, pfm_event_attr_info_t
>> *info);
>>
>>
>> Notice the new is_alias and the alias string which is valid only if
>> is_alias
>> is set. it contains the event string describing how the alias build on the
>> original event, e.g., with hardwired modifiers.
>
> You could get rid of is_alias here too.
>
> I'm not convinced it's necessary, but I don't see a way for the tool to be
> able to tell that a set of attributes are part of a group from which one
> alternative must be chosen.
>
> Otherwise, the interface looks like it has everything that's needed, and
> would be straight-forward to use.
>
> Just to pick a nit here... do you think "alias" is the best name for the
> mechanism? To me, alias means "another name for the same thing", and that's
> not really what this mechanism is doing. It denotes a variation of an
> existing event (or attribute). In some cases, the variation may expand the
> what events are counted, and in other cases contract them, or in some cases
> measure different things. Maybe you could use "variant_of" (or just
> "variant") instead?
>
> Regards,
>
> - Corey
>
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> cjash...@us.ibm.com
>
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
