> Thinking about it, (like regular vectored IO) it makes sense to return > success if we already queued up part of IO, in case of and error. > Isn't it ? This way, one can go and wait for those IOs to finish.
Doesn't make a lot of sense to me, but then I'm probably missing something by having seen about zero context for this notion of merging two radically different I/O models. Got any URLs for LKML discussion about that? AIO is all about one thing: decoupling the submission of an I/O request from its completion. Applications can issue any number of requests and let them complete whenever the OS manages it ... then apps will collect completion status whenever it's convenient to them. Usefully, it's an exact match for the low level I/O model of usb_request (on the peripheral or gadget side) or URB (on the host side). Call it non-threaded I/O and you'd be on the track of what folk like most about it. And likewise, what bothers a few relgious nuts most deeply about it ... but generally, not anyone who writes code that talks directly with the hardware. ;) readv/writev is all about a different thing: coupling the synchronous issuance and completion of a _group_ of related requests. It does not map directly to any of the controller level interfaces of USB, and the closest match is the synchronous scatterlist API ... a library on top of usbcore. The synchronization is explicitly threaded, and there's some very careful attention paid to fault semantics (at least, in USB there is). I think you can see why I'm wondering about the basic concept underlying those patches. I could understand writing a library to map readv/writev calls into aio, and arranging to use that for filetypes that don't have any direct implementation for those syscalls; easy to agree to that. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
