On Fri, Jul 31, 2015 at 12:31:58AM -0700, Christoph Hellwig wrote: > On Thu, Jul 30, 2015 at 05:42:16PM -0400, Doug Ledford wrote: > > I have no problem with this code. That Al finds the user space ABI for > > this driver to be bizarre is neither here nor there to me. Sure, this > > file does not exhibit normal file API behavior. Who cares? > > Everyone who cares about filesystem semantics does. > > A NACK from me for a this features, and b) for trying to sneak it in > after a negative comment without cc to -fsdevel and Al. FWIW, the lack of comments appears to have tripped Doug, judging by his "another option would be to drop the write function altogether and just make all commands come through writev/write_iter and if you only have one command, you only send one element". The thing is, ipath and qib (and AFAICS this one as well) have write(2) and writev(2) take different and completely unrelated sets of commands. On the same file. IOW, the effects of writev(fd, &(struct iovec){buf, len}, 1) and write(fd, buf, len) are not even remotely similar. _That_ is the gratuitous weirdness I'd been unhappy with. And yes, it is gratuitous - it's trivial to have separate files for separate command sets. If you drop ->write() in there, you certainly lose the weirdness - along with one of those command sets. Sure, having individual iovecs correspond to separate datagrams is fine; tons of drivers are like that. qib and ipath are unique, though, in having *two* command sets overloaded on the same file, with write() vs. writev() acting as selector (BTW, single-element AIO going like writev(), not like write()). PS: I'm back after several weeks of being sick (recipe for fun: start with 40C in shade, get completely soaked in serious rain, then have half an hour cab ride, with AC set to ~15C) and while I'd managed to get the mailbox down to relatively sane size, I might have easily deleted more than I should have. If there had been anything important sent my way and I don't reply to it by Saturday, please resend. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html