We tried again with an unpatched libpfm and got a Bad File Descriptor error message. At least it looks like it's getting into the kernel now. Any clues?
[EMAIL PROTECTED]:~> uname -a Linux anaka 2.6.24-perfmon2 #2 SMP Tue Apr 1 14:06:29 EDT 2008 ia64 ia64 ia64 GNU/Linux - d > -----Original Message----- > From: Dan Terpstra [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2008 4:40 PM > To: 'stephane eranian'; 'perfmon2-devel@lists.sourceforge.net' > Subject: RE: [perfmon2] libpfm syscall patch > > Stephane - > We applied your patch to a fresh checkout of libpfm and tried it on our > newly patched Montecito. It failed with a "function not implemented" error > on a call to pfm_create_context. I'm guessing there needs to be a separate > case in the switch for Montecito. I only saw a generic __ia64__ > We'll try again with an unpatched fresh copy of libpfm. > - dan > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:perfmon2- > devel- > > [EMAIL PROTECTED] On Behalf Of stephane eranian > > Sent: Thursday, April 03, 2008 10:12 AM > > To: perfmon2-devel@lists.sourceforge.net > > Subject: [perfmon2] libpfm syscall patch > > > > Hello, > > > > I got tired of having to maintain different revisions for libpfm, one > > each time the perfmon syscalls > > change. Sometimes back ward compatibility is not possible because the > > perfmon API/ABI changed. > > But nowadays, changes are happening inside the kernel not so much at > > the user level. > > > > There have been several new system calls in recent kernels. Those push > > the perfmon syscalls up > > on every architectures. > > > > Libpfm provides the syscall stubs to call the kernel perfmon API. > > Those stubs will eventually migrate > > into libc. The syscall numbers were kept in include/perfmon/perfmon.h > > and had to be updated for each > > new kernel version. The problem is that backward compatibility > > (whenever possible) was not provided. > > > > I have created the attached patch to address this problem. The same > > libpfm can now be used between > > kernel revisions as long as the perfmon API does not change. This is, > > for instance, the case between > > 2.6.24 and 2.6.25 for instance. The trick is to have the code > > autodetect the kernel version and adjust > > the syscall accordingly. Another solution would have been to have the > > kernel export the base syscall > > number via, let's say, /sys/kernel/perfmon/syscall. > > > > I am still hoping we will be in mainline soon, or at least that we > > will get a fixed block of syscalls soon, > > at which point, all of this will not be needed anymore, except for > > special platforms such as Cray. > > > > I have tested the attached patch on 2.6.25 on X86-64, i386. Please > > test it on your platforms and > > report any problem. > > > > Thanks. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
