Any USB gadget AIO interface users?
Has anyone successfully used the asynchronous I/O gadgetfs interface before? Specifically, has anyone used it for high-bandwidth isochronous traffic?
I ask because I remember discovering about four years ago that there were several brain-twisty bugs in the in-kernel asynchronous I/O layer that gadgetfs uses. The AIO core also seemed to be largely unmaintained. Is this still true?
Sarah Sharp
Quoted 7 lines · Sarah Sharp
Has anyone successfully used the asynchronous I/O gadgetfs interface before? Specifically, has anyone used it for high-bandwidth isochronous traffic?
I ask because I remember discovering about four years ago that there were several brain-twisty bugs in the in-kernel asynchronous I/O layer that gadgetfs uses.
Weren't they addressed? And are you looking to use the gadgetfs aio interface now, or are you looking to get rid of it? In other words, what's the real motivation behind the question?
Quoted 2 lines
The AIO core also seemed to be largely unmaintained. Is this still true?
Surely you should at least cc the aio list when asking such a question! Anyway, the aio core is maintained by several folks, but nobody is doing active development in that area, to my knowledge.
Cheers,
Jeff
Quoted 6 lines · Jeff Moyer
Quoted 4 lines · Sarah Sharp
Has anyone successfully used the asynchronous I/O gadgetfs interface before? Specifically, has anyone used it for high-bandwidth isochronous traffic?
Quoted 7 lines
Quoted 3 lines
I ask because I remember discovering about four years ago that there were several brain-twisty bugs in the in-kernel asynchronous I/O layer that gadgetfs uses.
Weren't they addressed? And are you looking to use the gadgetfs aio interface now, or are you looking to get rid of it? In other words, what's the real motivation behind the question?
I was looking to use it. The bug in question I remember was about cancellation, but I would have to dig in my mailbox from 2007 to find the exact issue.
The biggest problem I remember when I was looking at using the aio core to replace the ioctls in the usbfs subsystem with true aio operations was there was an issue with operation ordering. In the kernel to userspace interface for USB, we want asynchronous operations to a particular file to be queued to the hardware in the order they are submitted. So if the userspace application submits asynchronous read A, then asynchronous read B, then the buffer for read B doesn't get queued to the USB host controller before the buffer for read A. Otherwise you get transmission reordering on the bus, and USB devices aren't very happy.
Quoted 6 lines
Quoted 2 lines
The AIO core also seemed to be largely unmaintained. Is this still true?
Surely you should at least cc the aio list when asking such a question! Anyway, the aio core is maintained by several folks, but nobody is doing active development in that area, to my knowledge.
Sorry, I forgot the aio mailing list existed. :) In 2007, there was lots of talk of using syslets or fibrils in the aio core, and Zack Brown had some patches for that, but it seemed like nothing really came out of that. Has anything new been added to the AIO core since then?
Sarah Sharp
Quoted 11 lines · Sarah Sharp
Quoted 10 lines · Jeff Moyer
Quoted 7 lines · Sarah Sharp
Has anyone successfully used the asynchronous I/O gadgetfs interface before? Specifically, has anyone used it for high-bandwidth isochronous traffic?
I ask because I remember discovering about four years ago that there were several brain-twisty bugs in the in-kernel asynchronous I/O layer that gadgetfs uses.
Quoted 7 lines
Quoted 3 lines
Weren't they addressed? And are you looking to use the gadgetfs aio interface now, or are you looking to get rid of it? In other words, what's the real motivation behind the question?
I was looking to use it. The bug in question I remember was about cancellation, but I would have to dig in my mailbox from 2007 to find the exact issue.
Reference counting in that path is usually the tricky part to get right. We had one person looking to make use of aio in his driver, iirc, and that was a major concern of his, as well. If we can get both of your requirements together, maybe we can make progress.
Quoted 10 lines
The biggest problem I remember when I was looking at using the aio core to replace the ioctls in the usbfs subsystem with true aio operations was there was an issue with operation ordering. In the kernel to userspace interface for USB, we want asynchronous operations to a particular file to be queued to the hardware in the order they are submitted. So if the userspace application submits asynchronous read A, then asynchronous read B, then the buffer for read B doesn't get queued to the USB host controller before the buffer for read A. Otherwise you get transmission reordering on the bus, and USB devices aren't very happy.
The AIO infrastructure doesn't guarantee that. It does the setup required in the context of the calling process, and then queues the operation to the underlying "device" (where device, in most cases, is a file or a block device, which means submit_bio is called). After that, the AIO code has no control over ordering. If there are specific ordering requirements in the application, then maybe AIO isn't the right fit. I don't know enough about your application to say.
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
The AIO core also seemed to be largely unmaintained. Is this still true?
Surely you should at least cc the aio list when asking such a question! Anyway, the aio core is maintained by several folks, but nobody is doing active development in that area, to my knowledge.
Sorry, I forgot the aio mailing list existed. :) In 2007, there was lots of talk of using syslets or fibrils in the aio core, and Zack Brown had some patches for that, but it seemed like nothing really came out of that. Has anything new been added to the AIO core since then?
Nothing came of it, no. There haven't been any attempts since, either.
Cheers,
Jeff