On Wed, 24 Jul 2013, Andi Kleen wrote: > Sorry I meant flags as an alias of "the 64bits currently occupied by the > bitfield". Perhaps the name choice was not very good. > > "flags_bitfield" ? > > So the tool would only need to know that, not every bit. > > In theory it could be also generalized as a byte offset to perf_event, > but that may be overengineered. I somehow doubt this would be acceptable. If it were, we could have had a somewhat better interface by just having the event fields be a list of values without involving format/* at all, something like config=0x58034;config1=0x20;precise_ip=0x4 For whatever reason things have to be human readable, and I don't think just having an opaque 64-bit "flags" value will be accepted. I'm likely wrong though, I have a very low accuracy rate for predicting future perf_event design decisions. This is all complicated by the intertwined nature of the perf_event ABI and the perf tool, and the way that there's at least three or four different ways to specify the same event from the perf tool command line. Vince -- To unsubscribe from this list: send the line "unsubscribe trinity" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
