On 04/04/2017 11:58 AM, Stephane Eranian wrote: > Hi, > > On Tue, Apr 4, 2017 at 8:44 AM, William Cohen <wco...@redhat.com> wrote: >> On 04/04/2017 12:59 AM, Stephane Eranian wrote: >>> Phil, >>> >>> On Mon, Apr 3, 2017 at 9:03 AM, Philip Mucci <mu...@icl.utk.edu> wrote: >>>> Hi Stephane, >>>> >>>> Please please consider this type of ABI change a compile time option. >>>> Breaking the ABI to use a set of hardware that most users don’t use (nor >>>> have permissions to use courtesy of our friend perf_event_paranoid) really >>>> doesn’t make sense. >>>> >>> I will revert this patch and release 4.9. >>> Would that solve your problem? >> >> Hi Stephane, >> >> RHEL 7 has libpfm-4.7, so having libpfm-4.9 would avoid the abi issue when >> in the future libpfm is rebased. >> > Ok, makes sense. > >> As far ask keeping this capability of raw umasks wider than 32 bits would it >> be possible to use some of reserved_bits for the additional part of the >> umask? There are 30 reserved bits there. >> > I reverted all the related changes last night and found another > internal way of supporting large raw umasks. The ABI is back to where > it was in 4.7. The issue was that internally in the parsing of the > event string the library was using the same struct > (pfm_event_attr_info_t) as the struct used to report event info. But > it did not have to be the same. Yesterday, I therefore created an > internal version of pfm_event_attr_info with uint64_t for idx and > updated all the internal interfaces and functions to use this. Only > the user visible function uses the ABI struct. > > Problem solved. I will test the patches some more before pushing them > to the repo.
If you would like, I can build a libpfm with the proposed patch and use libabigail to verifiy abi is unchanged. -Will > > As for the LDCONFIG issue raised by Phil, I will do -$(LDCONFIG). When > you run as root, it will do ldconfig. When you run as regular user, > you will not update the dynamic loader cache and will not create the > symlink. > > >> -Will >>> >>>> phil >>>> >>>> On Apr 1, 2017, at 1:03 AM, Stephane Eranian <eran...@googlemail.com> >>>> wrote: >>>> >>>> Ok, my bad. That was not my goal here. >>>> We can revert this change. But to enable support, this struct will >>>> need to change. >>>> So it will incur some ABI change. >>>> >>>> >> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
