Thanks for your reply, Stephane. Just a bit more below: > Corey, > > On Wed, Sep 24, 2008 at 1:07 AM, Corey Ashford <[EMAIL PROTECTED]> wrote: >> A few comments/questions below: >> >> "stephane eranian" <[EMAIL PROTECTED]> wrote on 09/23/2008 02:32:24 PM: >
[snip] >> > II) programming the registers >> > >> > With v2.81: >> > int pfm_write_pmcs(int fd, pfarg_pmc_t *pmds, int n); >> > int pfm_write_pmds(int fd, pfarg_pmd_t *pmcs, int n); >> > int pfm_read_pmds(int fd, parg_pmd_t *pmds, int n); >> > >> > With v3.0: >> > int pfm_write_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n); >> > int pfm_write_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n, >> > pfarg_pmd_attr_t *pmas); >> > >> > int pfm_read_pmrs(int fd, int flags, pfarg_pmr_t *pmrs, int n); >> > int pfm_read_pmrs(int fd, int flags, parg_pmr_t *pmrs, int n, >> > pfarg_pmd_attr_t *pmas); >> > >> >> The 'a' in pma stands for "attributes" I assume? >> > Yes. > >> Chances are unlikely for it to actually happen, but what if, in the >> future, you found you need to add another register type, with its own >> attributes? Would the type of the final parameter be different? Should >> that maybe be a "void *pmas" instead, or is using "void *" seriously >> frowned upon in kernel circles? >> > > This is an interesting question. In the current proposal, pfarg_pmd_attr > is specifically meant for PMD registers. If is ignored for PMC registers. > Should we need to add a new type, let's call it FOO, then we would > add a new flag PFM_RWFL_FOO, we would still use the pfarg_pmr_t > structure for the basic description. Then if FOO needs some extra, we > would add another parameter after pfarg_pmd_attr, it would be called > pfarg_foo_attr. You would call as follows: > pfm_write_pmrs(fd, PFM_RWFL_FOO, pmrs, 1, NULL, foo); > Is there a hard limit on the number of kernel parameters that can be passed? If there is and the number is relatively low, it would limit the number of register types you could add in this way. > Now if we generalize pfarg_pmd_attr and call it pfarg_pmr_attr, then we could > leverage the reserved fields. We would still need the PFM_RWFL_FOO and > it would cause the kernel to only pick at the new fields in pfarg_pmr_attr. That doesn't sound like a good idea. You'd start mixing the attributes used among several register types (or create a variant record using a union), and it could complicate revisioning. Plus this would mean that you would be copying more data to/from user space all register types with attributes. trade-offs trade-offs! [snip] >> The amount of data copied to and from the kernel for pmd read/write the >> same as in 2.81, right? >> > If you use the attributes then yes, you copy exactly the same as with v2.81. > But the nice thing is that you don't have to pass them if you don't need them. > You can call as follows: > > pfm_write_pmrs(fd, PFM_RWFL_PMD, pmrs, 1); > > And with attributes: > > pfm_write_pmrs(fd, PFM_RWFL_PMD_ATTR, pmrs, 1, pmas); > > There is the assumption that the pmas vector is as big as the pmrs vector, so > we > can avoid having a count for pmas. > I see now, thanks. I missed the fact that there are two possible flags that can be passed to write pmd registers. Reagards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ perfmon2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
