On Fri, 3 Feb 2006, David Brownell wrote: > > 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's not really a group of related requests; it's a single request for which the memory buffer consists of several discontiguous pieces. This is a significant distinction. With readv/writev you specify a single starting offset in the file, whereas with multiple requests you would have multiple starting offsets. > 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). (Slightly off-topic... Do you think it would make sense to move scatterlist support directly into the host controller drivers? We already have something very much like it in place for iso transfers. It could save a lot of work allocating URBs and such if we used it for large bulk transfers.) > 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. The idea makes sense to me. iovecs and aio are essentially orthogonal concepts, and the most general implementation would support both. An iovec would correspond to a single aio transfer, the only difference being that the memory buffer is scattered. Once you think of it like that, it's clear that an I/O submission either fails immediately or else completes some time later. When it is complete, the user should be able to find out how much data was transferred and retrieve an error code (if the transfer terminated early because of an error). Badari's patch didn't seem to behave this way, which is why I raised the question initially. Alan Stern ------------------------------------------------------- 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
