[lkml]   [2004]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: drivers/block/ub.c
    Pete Zaitcev wrote:

    > This posting is largely a "release early release often" excercise, as
    > Papa ESR taught us. But you can see the design outline clearly now,
    > I hope, and I'm interested in feedback on that.

    What hardware have you tested it with? It'd be good to know that it
    works on Linux hardware running Alan's "File Storage Gadget" driver.
    Which means most everything, given dummy_hcd ... :)

    > +config BLK_DEV_UB
    > + tristate "Low Performance USB Block driver"

    Hmm, I'd have thought "low overhead" ... isn't that one
    of the goals of omitting the SCSI layer?

    > + /*
    > + * We do not support transfers from highmem pages
    > + * because the underlying USB framework does not.
    > + *
    > + * XXX Actually, there is a (very fresh and buggy) support
    > + * for transfers under control of struct scatterlist, usb_map_sg()
    > + * in 2.6.6, but it seems to have issues with highmem.
    > + */

    I could easily believe highmem issues, but there's nothing
    preventing USB from handing highmem pages. The HCDs just
    use the DMA addreses given to them, and don't care if that's
    a highmem page, an ioummu mapped address, or a bounce buffer
    allocated by dma mapping or other code.

    That code isn't "very fresh and buggy", having been in use
    with all USB-Storage devices for over a year and a half.
    The bugs I've heard about have been either "device doesn't
    work correctly at its peak transfer rate" (sigh) or, without
    many recent reports, "wedged in cleanup after error".

    > + /*
    > + * This is a serious infraction, caused by a deficiency in the
    > + * USB sg interface (usb_sg_wait()). We plan to remove this once
    > + * we get mileage on the driver and can justify a change to USB API.
    > + * See blk_queue_bounce_limit() to understand this part.
    > + */
    > + q->bounce_pfn = blk_max_low_pfn;
    > + q->bounce_gfp = GFP_NOIO;

    Well, out with it then -- what deficiency would that be? :)

    It's true that EHCI doesn't do 64bit DMA on those Intel boxes,
    but that's hardly a "serious" problem.

    - 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: 2005-03-22 14:04    [W:0.022 / U:0.264 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site