linux-kernel - Re: [perfmon] Re: [perfmon2] perfmon2 merge news

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071114110009.GA17833@infradead.org>
Date:	Wed, 14 Nov 2007 11:00:09 +0000
From:	Christoph Hellwig <hch@...radead.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, Philip Mucci <mucci@...utk.edu>,
	eranian@....hp.com, William Cohen <wcohen@...hat.com>,
	Robert Richter <robert.richter@....com>,
	linux-kernel@...r.kernel.org, Perfmon <perfmon@...ali.hpl.hp.com>,
	Andi Kleen <andi@...stfloor.org>,
	perfmon2-devel@...ts.sourceforge.net,
	OSPAT devel <ospat-devel@...utk.edu>,
	papi list <ptools-perfapi@...utk.edu>
Subject: Re: [perfmon] Re: [perfmon2] perfmon2 merge news

On Wed, Nov 14, 2007 at 09:43:02PM +1100, Paul Mackerras wrote:
> Christoph Hellwig writes:
> 
> > Mine for example.  The whole userspace interface is just on crack,
> > and the code is full of complexities aswell.
> 
> Could you give some _technical_ details of what you don't like?

I've done this a gazillion times before, so maybe instead of beeing a lazy
bastard you could look up mailinglist archive.  It's not like this is the
first discussion of perfmon.  But to get start look at the systems calls,
many of them are beasts like:

  int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)

This is basically a read(2) (or for other syscalls a write) on something
else than the file descriptor provided to the system call.   The right thing
to do is obviously have a pmds and pmcs file in procfs for the thread beeing
monitored instead of these special-case files, with another set for global
tracing.  Similarly I'm pretty sure we can get a much better interface
if we introduce marching files in procfs for the other calls.

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