On Wednesday 14 November 2007 22:58, David Miller wrote: > From: Nick Piggin <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 10:49:48 +1100 > > > On Wednesday 14 November 2007 22:44, Paul Mackerras wrote: > > > David Miller writes: > > > > This is my impression too, all of the things being done with > > > > a slew of system calls would be better served by real special > > > > files and appropriate fops. > > > > > > Special files and fops really only work well if you can coerce the > > > interface into one where data flows predominantly one way. I don't > > > think they work so well for something that is more like an RPC across > > > the user/kernel barrier. For that a system call is better. > > > > > > For instance, if you have something that kind-of looks like > > > > > > read_pmds(int n, int *pmd_numbers, u64 *pmd_values); > > > > > > where the caller supplies an array of PMD numbers and the function > > > returns their values (and you want that reading to be done atomically > > > in some sense), how would you do that using special files and fops? > > > > Could you implement it with readv()? > > Sure, why not? Just cook up an iovec. pmd_numbers goes to offset > X and pmd_values goes to offset Y, with some helpers like what > we have in the networking already for recvmsg. > > But why would you want readv() for this? The syscall thing > Paul asked me to translate into a read() doesn't provide > iovec-like behavior so I don't see why readv() is necessary > at all.
Ah sorry, that's what I get for typing before I think: of course readv doesn't vectorise the right part of the equation. What I really mean is a readv-like syscall, but one that also vectorises the file offset. Maybe this is useful enough as a generic syscall that also helps Paul's example... Of course, I guess this all depends on whether the atomicity is an important requirement. If not, you can obviously just do it with multiple read syscalls... - 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/
