Boaz Harrosh <bharrosh@xxxxxxxxxxx> writes: >>> I also pondered simply adding a new io_prep_* function + IO_CMD_ code to libaio >>> and all the other plumbing necessary to make that happen... >>> >>> void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov, >>> int iovcnt, long long offset, const void *pi, >>> size_t pi_count); >>> >> This is also what I've envisioned. >> Updating io_prep / async I/O is reasonably easy as its been using a >> separate structure for passing in the I/O details. >> >> Normal read/write calls don't really map as you simply don't have >> enough parameter to feed PI information into the kernel. >> So for that you'd need to invent a new interface / syscall. >> >> For aio we just need to add additional fields to an existing structure. >> >> So yeah, I'd be interested in that discussion as well. Sure, it's easy to start there, but then you eventually end up having to add a non-aio interface as well. Let's not take the latter off the table. > Me too, in multiple fronts. It's part of my general concern about > "things we would like for user-mode servers" > > I think that the current aio and libaio Interface is broken for a long > time, for multitude of reasons. For instance the nested structure definitions > are COMPAT broken News to me. I run the libaio test harness built with -m32 on 64 bit regularly. What, exactly, is broken? > , and lots of missing pieces. (For example search in archives > for why bsg does not support sg-lists.) > And there are all these additions that everyone wants on top, that call for > a new interface anyway. What was proposed above does not require a new interface. It's just an additional IO_CMD_*. I'm not saying there aren't reasons for a new interface, it's just I didn't see any in this thread. > So I would like to see a deep fixup of this interface, with an aio version2 > that can take into considerations, all of future needs including these > above. Kernel code will be very happy to be implemented with the new, interface > and a COMPAT layer could be put in place for the old interface. > > All interested parties should bring to the table what is the extension/changes > they need. And we can try and union all of them together. > > (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy > I know that qemu was wanting this for a while as well as the multitude of > user-mode servers) I'm not sure how that's directly related to aio, but ok. If we're going to rewrite the aio code, I think Zach's acall would be a good start, at least on the API front: http://lwn.net/Articles/316806/ Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
