Hello, On Wed, Nov 14, 2007 at 10:39:24PM +1100, Paul Mackerras wrote: > Christoph Hellwig writes: > > > 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. > > No it's not basically a read(). It's more like a request/reply > interface, which a read()/write() interface doesn't handle very well. > The request in this case is "tell me about this particular collection > of PMDs" and the reply is the values. >
Exactly. This is not a brute force read()! On input you pass the list of registers you want to read. Upon return, you get the list of values. Now, I think the current call could be optimized even more by making the structure smaller. Today, the structure passed read/write PMD registers is the same. On write, we pass other information such as the reset values (sampling periods), randomization parameters and some flags. They are not needed on read. > It seems to me that an important part of this is to be able to collect > values from several PMDs at a single point in time, or at least an > approximation to a single point in time. So that means that you don't > want a file per PMD either. > Yes, we want to be able to read one or many registers in one call. The number of PMU counters is not going to shrink, so having a file descriptor per register looks overkill to me. > Basically we don't have a good abstraction for a request/reply (or > command/response) type of interface, and this is a case where we need > one. Having a syscall that takes a struct containing the request and > reply is as good a way as any, particularly for something that needs > to be quick. > -- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/