linux-kernel - Re: [patch 00/24] perfmon: introduction

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]

Message-ID: <7c86c4470811260538s351899d3x31c3df1ad994add7@mail.gmail.com>
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/