mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sarah Sharp <sarah.a.sharp@linux.intel.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-usb@vger.kernel.org, libusb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-aio@kvack.org
Subject: Re: Any USB gadget AIO interface users?
Date: Wed, 23 Mar 2011 12:02:05 -0700	[thread overview]
Message-ID: <20110323190205.GC5947@xanatos> (raw)
In-Reply-To: <x49vcz9c3dr.fsf@segfault.boston.devel.redhat.com>

On Wed, Mar 23, 2011 at 10:34:08AM -0400, Jeff Moyer wrote:
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> 
> > 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?

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.

> > 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

  reply	other threads:[~2011-03-23 19:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 17:12 Sarah Sharp
2011-03-23 14:34 ` Jeff Moyer
2011-03-23 19:02   ` Sarah Sharp [this message]
2011-03-23 20:50     ` Jeff Moyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110323190205.GC5947@xanatos \
    --to=sarah.a.sharp@linux.intel.com \
    --cc=jmoyer@redhat.com \
    --cc=libusb-devel@lists.sourceforge.net \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®