[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070531152134.GA974@infradead.org>
Date: Thu, 31 May 2007 16:21:34 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Stephane Eranian <eranian@...nkl.hpl.hp.com>
Cc: linux-kernel@...r.kernel.org, eranian@....hp.com
Subject: Re: [PATCH 03/22] 2.6.22-rc3 perfmon2 : new system calls support
On Tue, May 29, 2007 at 06:48:17AM -0700, Stephane Eranian wrote:
> sys_pfm_create_context():
> - create a new perfmon2 context and returns a file descriptor in
> the pfarg_ctx_t parameters. This is the first call an application
> must make to do monitoring
> - rewritten to pass sampling format identification as a string
> - file descriptor is now returned by call
>
> sys_pfm_write_pmcs():
> - program the PMU configuration registers. Accepts vector of arguments
> of type pfarg_pmc_t
>
> sys_pfm_write_pmds():
> - program the PMU data registers. Accepts a vector of arguments of type
> pfarg_pmd_t
>
> sys_pfm_read_pmds():
> - read the PMU data registers. Accepts a vector of arguments of type
> pfarg_pmd_t
This kind of interface doesn't make any sense at all. Information should
be read and written from filedescriptors using the read and write family
syscalls and through the VFS instead of adding tons of system calls.
I fear we need to write down the requirements first and then come up
with something better. E.g. for per-task sampling an interface centered
around a few files in /proc/<pid>/ would fit very nicely:
/proc/<pid>/perfmon_pmcs
/proc/<pid>/perfmon_pmds
Obvious
/proc/<pid>/perfmon_ctl
Can get control commands as ascii sets written to
-
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