Philip Mucci wrote: > Hi Stefane, > > Yeah, we talked about this on the phone. I personally think an > attribute versus a umask is an unnecessary semantic distinction. Both > could be handled by the umask mechanism as far as I can see. > i.e. When you parse a umask, you see an equal sign, you treat it as > such... Further, umasks can simply be seen as shorthand for the > attribute umask=true or something to that effect. In this way, we also > don't need any new API calls specific to attributes... > > Let's see what other folks think.. >
I agree with this. I think it makes it easier to understand the interface too... "What's the difference between a umask and an attribute, exactly?", I would want to know. We could call them all attributes, or all umasks. Personally, I prefer the term attribute, as it gets at the heart of what they are for. As for the encoding of PCL events, I like the idea of unifying the user/kernel/supervisor as attributes/umasks and then processing that into an entire pcl perf_hw_counter struct. However, libpfm has attempted to disconnect itself from the kernel implementation, and adding this sort of kernel-specific function is taking a rather long drive down that road. Plus it makes libpfm more closely tied to the version of PCL which is in the kernel. In that light, at least until PCL settles down very well, I think the "simply provide raw encoding (no PCL encoding)" option would be preferable. (by the way, is the "uint64_t vals" param supposed to be a pointer "uint64_t *vals" ?) I have a few comments about "libpfm: event table encoding": One of the things I like about libpfm is that the tables are hard-coded which means they are always there and libpfm doesn't have to contain a bunch of crumbly logic to locate the events file (and possibly find the wrong one). Java has a nice way of dealing with issues like this, where a class can read a file contained in its own jar file (which a user could replace with his own version), but I don't think .so files have any such mechanism, but there are packaging technologies for most *nixes that would handle this just fine (rpm, etc.). I think there's little motivation to go with anything other than XML for this, if you want to do it. There are some decent XML parsing libraries out there that should suit the needs of libpfm (expat and libxml2). You'd probably want to distribute an XML schema or DTD file for each architecture too, so that the libpfm could validate that the syntax of the event file is correct for that arch. Functions for both are in libxml2. I should be clear to say that I have never used either library, but I have used similar libraries in Java. Once you read in the XML file and convert it to an in-memory structure, you wouldn't need to access the file system anymore. So I'm not sure where the "bursty accesses on shared storage" problem comes in. If you accessed the XML tables via the DOM, the potential is there to use more memory than would be required by having loaded the hard-coded event tables for all arches. However, if you use SAX instead, the memory overhead should be minimal, and both expat and libxml2 support a SAX interface. - Corey ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
