Kevin, > Why is there a get_num_counters() API, instead of simply a numerical field in > the pfm_pmu_support_t structure like there is for pmc_count and pmd_count? > Again, what's the distinction between PMCs, PMDs, and counters? >
Ok, I fixed that now. > Another note about the arch-specific module APIs - there seems to be a lot of > inconsistency in how parameters and return values are passed. For instance, You have to be careful here. Some routines are below the generic layer, e.g., pfm_ita2_get_event_name(). Others are user interface that are arch-specific, e.g., pfm_ita2_get_event_maxincr(). In general you can tell by verifying whether the function is declared static or not. Not the greatest test, I agree. I wanted to avoid re-using the same name in each file to avoid confusion when debugging. But I think it would make it easier to distinguish between arch-private interface and implementation of the generic interface. We could say pfm_arch_get_event_name() for something needed for the generic interface and keep the pfm_ita2_ prefix pattern. > get_event_code() returns the code via pointer, but get_event_vcode() simply > returns the vcode directly. Also, get_event_code() now takes a PMD number but > get_event_vcode() doesn't. The get_event_name() routine simply returns a I got rid of get_event_vcode(), it was useless information for end-users. -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
