lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 20 Feb 2009 09:10:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephane Eranian <eranian@...glemail.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	"David S. Miller" <davem@...emloft.net>,
	Mike Galbraith <efault@....de>
Subject: Re: [announce] Performance Counters for Linux, v6


* Corey Ashford <cjashfor@...ux.vnet.ibm.com> wrote:

> Ingo Molnar wrote:
>> We are pleased to announce version 6 of our performance counters 
>> subsystem implementation. The shortlog, diffstat and the combo patch 
>> can be found below. The combo patch against latest -git (2.6.29-rc2) 
>> can be also found at:
>>
> [snip]
>
> Hi Ingo,
>
> As I was starting to put together a simple implementation of 
> PAPI on top of PCL for Power, I noticed that PCL does not seem 
> to have any sort of versioning and way of ascertaining the 
> current capabilities of what is in the kernel.
>
> This information is needed by tools and libraries built on top 
> of PCL so that they can know what is supported and if any bugs 
> need to be worked around.

I'd prefer to use the standard Linux syscall ABI convention 
here:

 - once upstream, existing functionality is compatible forever

 - new functionality is added in a way that it generates a 
   -ENOSYS return from the syscall in an older kernel.

That's why the event structure is sized relatively large for 
example - to make sure we have space to grow into.

So instead of adding versioning information, it would be very 
nice if you could check the ABI details for 'traps' that make 
extensions harder. Try to come up with pie-in-the-sky future 
items you'd like to see in the ABI, and lets see how supportable 
it would be.

Example #1 - made up. Say if we had an ABI detail like this:

  struct perf_counter_hw_event {
          u8                     type;

this would limit us to 256 events - which would be clearly 
stupid as we can easily hit that limit.

Example #2. Not made up:

asmlinkage int
sys_perf_counter_open(struct perf_counter_hw_event *hw_event_uptr __user,
                      pid_t pid, int cpu, int group_fd)

Those are 5 parameters - we could extend it to 6 and add a 
'flags' value that in the current version will return -ENOSYS if 
the flags value is not zero.

This would add one more dimension of extensibility to the 
interface.

If you could come up with a list of small details like this, 
that would be really helpful. Would this work?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ