Phil, On Sun, Jul 23, 2006 at 12:21:00PM +0200, Philip Mucci wrote: > Hi Stefane, > > I think sensible interpretations are A Good Thing for APIs, don't you > agree? > Yes.
> This would mean a change to both the code for I386 and IA64, to make > PFM_PLM0 be kernel mode. At the moment, the only way to figure out what > is what for any given platform is to dig through the source. In libpfm today, each PMU specific module is responsible for interpreting the meaning of PFM_PLM*. Yet the definition of the macros is in the generic pfmlib.h file (the is useful for building generic test/example programs). The associated comments, though, are not generic. Based on your comments, I have made some changes. The generic header (pfmlib.h) does not provide any intepretation, it just lists 4 levels. Then you document in each arch/pmu specific header file how the levels are interpreted. I have pushed this into CVS now. I provided the interpretation for MIPS, hope this is correct. Tell me if you are more conformtable with this model? Thanks. > > Anyways, this is just a suggestion. I work with the sources, so there's > no problem for me. But I believe that not having any standardized > meaning for PFM_PLMs when there most certainly are standardized > definitions of SUPERVISOR, INTERRUPT, KERNEL and USER modes is a bit of > a mistake. > > At the very least, we should change the kernel comment in the header > file. But currently, the comments are just wrong, kernel mode isn't hre > most privileged and this confuses things for PPC64, MIPS and > virtualizable implementations of the x86/x86_64 and IA64. > > Anyways, just a suggestion. > > Phil > > > > On Fri, 2006-07-21 at 13:01 -0700, Stephane Eranian wrote: > > Phil, > > > > Using the PFM_PLM* is just a matter of interpretation for your platform. > > > > For what I can see from your proposal you have not changed anything > > to the existing code. You just changed the comments (interpretation). > > The good thing about using a numbering scheme as opposed to > > explicit names (e.g, KERNEL, INTR, USR, ...) is that it is up > > to each platform to map this to their actual priv levels. > > > > > > On Fri, Jul 21, 2006 at 01:21:08PM +0200, Philip Mucci wrote: > > > Hi folks, > > > > > > Would people care to standardize the definitions of PFM_PLM? > > > > > > Currently they are different for different architectures. This isn't so > > > much of an issue on x86, but on PPC64, MIPS and others that have > > > hypervisor modes, it seems like we should go from this: > > > > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM0 > > > 0x1 /* kernel level (most privileged) */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM1 > > > 0x2 /* priv level 1 */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM2 > > > 0x4 /* priv level 2 */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM3 > > > 0x8 /* user level (least privileged) */ > > > > > > > > > To this: > > > > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM0 > > > 0x1 /* supervisor level (most privileged) */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM1 > > > 0x2 /* interrupt level */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM2 > > > 0x4 /* kernel level */ > > > libpfm-3.x/include/perfmon/pfmlib.h:#define PFM_PLM3 > > > 0x8 /* user level (least privileged) */ > > > > > > To change this in the current base would simply mean altering some low > > > level code in PFM. MIPS is currently the latter since it supports all > > > modes. > > > > > > Comments? > > > > > > Phil > > > > > > > > > _______________________________________________ > > > perfmon mailing list > > > [email protected] > > > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ > > > > _______________________________________________ > perfmon mailing list > [email protected] > http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/ -- -Stephane _______________________________________________ perfmon mailing list [email protected] http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
