On Mon, 2013-03-04 at 15:21 +1100, Michael Ellerman wrote: > Make it explicit that the format attributes may define overlapping bit > ranges. Unfortunately this was left unspecified originally, and all the > examples show non-overlapping ranges. I don't believe this is an ABI > change, as we are defining something that was previously undefined, but > others may disagree. > > The POWER8 PMU would like to define overlapping ranges, as bit ranges in > the event code have different meanings for certain events. It will also > allow us to define an overarching "event" field, that encompasses all > others. > > As far as I can see perf is comfortable with this change, however I am > not sure if there are any other users of the interface. > > Signed-off-by: Michael Ellerman <michael@xxxxxxxxxxxxxx> > --- > Documentation/ABI/testing/sysfs-bus-event_source-devices-format | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format > index 079afc7..77f47ff 100644 > --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format > +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format > @@ -9,6 +9,12 @@ Description: > we want to export, so that userspace can deal with sane > name/value pairs. > > + Userspace must be prepared for the possibility that attributes > + define overlapping bit ranges. For example: > + attr1 = 'config:0-23' > + attr2 = 'config:0-7' > + attr3 = 'config:12-35' > + > Example: 'config1:1,6-10,44' > Defines contents of attribute that occupies bits 1,6-10,44 of > perf_event_attr::config1. ISTR discussing this with Jiri at some point.. I think we ended up with being fine with overlapping ranges but having perf issue a warning (not an error) when attributes of a single event have overlap. I'm not sure the latter was ever implemented in the userspace side. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
