linux-kernel - Re: [PATCH v3] perfcounters: record time running and time enabled for each counter

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <18890.58987.604249.823917@drongo.ozlabs.ibm.com>
Date:	Thu, 26 Mar 2009 13:20:27 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3] perfcounters: record time running and time enabled
 for each counter

Peter Zijlstra writes:

> Paul, should we perhaps also put a format header in the sys_read()
> output?

Hmmm..., possibly.  It could be useful to have a PERF_FORMAT_GROUP,
and then we'd want headers, I guess.

However, to simplify life for userland, we should make it possible to
predict the layout for the simple cases (the cases where they have
only asked for fixed-length items).  For example, if the user only
wants the counter value, they should be able to do the read() and know
that the counter value is at some fixed offset in the buffer they just
read, provided they got the number of bytes they expected.  It would
be unfortunate if we have to have code to step through a series of
tagged records to find the counter value, and additionally have code
to cope with not finding the tag we're expecting.

Paul.
--
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/