[lkml]   [2007]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops
    On Tuesday 16 January 2007 1:13 am, Nate Diller wrote:
    > On 1/15/07, David Brownell <> wrote:
    > > What's needed is an async, non-sleeeping, interface ... with I/O
    > > overlap. That's antithetical to using read()/write() calls, so
    > > your proposed approach couldn't possibly work.
    > haha, wow ok you convinced me :)

    Good. :)

    > I got a bit impatient when I was working on this, it took some time
    > just to figure out the intention of the code, and I'm trying to hold
    > to a bit of a schedule here. Without any clear (to me) reason, I
    > didn't want to spend a lot of effort fixing this up.

    Thing is, it's not OK to break other subsystems like that.

    > There's really no big difference between the usb drivers here and the
    > disk I/O scheduler queue, AFAICT,

    The disk scheduler queue is more complex, as I understand things,
    since it can combine operations. For USB, "combining" would break
    essential semantics relied on by both sides of the transaction.

    Maybe the best way to view this is to accept that with USB, all
    scheduler operations (e.g. for bandwidth reservation management)
    are out of scope of the AIO request model. AIO requests are no
    more (or less) than "append this to the endpoint's I/O queue",
    with the (host side) I/O scheduling handled separately.

    > so it seems like the solution I want
    > is to do a kmap() on the user buffer and then do the I/O straight out
    > of that. That will eliminate the need for the bounce buffer. I'll
    > post a new version along with the iodesc changes later this week.

    Sounds more complex, but it would be nice to have that code become
    zero-copy instead of single-copy. That'd let some platforms work
    with high bandwidth ISO from userspace, which previously would not
    have had enough CPU bandwidth. ("High bandwidth" means sustained
    8-24 MByte/sec data streaming. Processing pixels at that rate may
    require a companion DSP...) Testing will be different issue though.

    - Dave
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-16 20:15    [W:0.023 / U:50.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site