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:	Wed, 26 Nov 2008 14:38:37 +0100
From:	"stephane eranian" <eranian@...glemail.com>
To:	"Paul Mackerras" <paulus@...ba.org>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	mingo@...e.hu, x86@...nel.org, andi@...stfloor.org,
	sfr@...b.auug.org.au
Subject: Re: [patch 00/24] perfmon: introduction

Hello Paul,

On Wed, Nov 26, 2008 at 11:05 AM, Paul Mackerras <paulus@...ba.org> wrote:
> eranian@...glemail.com writes:
>
>> This new version, named perfmon3, uses only 5 system calls (instead of 12).
>> Each call was carefully designed to allow for future extensions.
>
> I notice that the userspace stuff in CVS assumes perfmon3 has 7 system
> calls, the 5 added here plus pfm_create_sets and pfm_getinfo_sets.
> Are you planning to add those two later (in which case we should
> reserve the numbers now), or are you going to implement the
> functionality of those two in pfm_write and pfm_read?
>

Yes, the LKML patchset represents the very minimal functionality of perfmon3.
Libpfm/pfmon are coded to support the fully-featured version to help
with testing
and evaluations.

The 2 systems calls you are referring to go with event set and multiplexing, an
advanced feature which I intend to submit to LKML later. That's why I
did not add
those two calls immediately. People would have argued that the calls are
not used.

Furthermore, there is still some discussions as to how best to add the
set functionality
to the syscall API. We need to be able to:
    - create new sets
    - retrieve runtime execution about sets, e.g., number of
activations, timeout left
    - and possibility delete sets

I don't think we can reserve syscall numbers in advance. OTOH, the
perfmon3 syscalls
don't necessarily need to be contiguous, unless people tell me this is
a rule used by
the kernel developers.
--
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