From: David Brownell <david-b@pacbell.net>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: greg@kroah.com, arjanv@redhat.com, jgarzik@redhat.com,
tburke@redhat.com, linux-kernel@vger.kernel.org,
stern@rowland.harvard.edu, mdharm-usb@one-eyed-alien.net,
oliver@neukum.org
Subject: Re: drivers/block/ub.c
Date: Sun, 27 Jun 2004 15:56:39 -0700 [thread overview]
Message-ID: <40DF50A7.1020404@pacbell.net> (raw)
In-Reply-To: <20040626130645.55be13ce@lembas.zaitcev.lan>
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
next prev parent reply other threads:[~2004-06-27 22:57 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-26 20:06 drivers/block/ub.c Pete Zaitcev
2004-06-26 20:12 ` drivers/block/ub.c Matthew Dharm
2004-06-27 2:08 ` drivers/block/ub.c Pete Zaitcev
2004-06-27 3:30 ` drivers/block/ub.c Matthew Dharm
2004-07-12 0:10 ` [usb-storage] drivers/block/ub.c Pat LaVarre
2004-06-26 20:35 ` drivers/block/ub.c Oliver Neukum
2004-06-26 21:41 ` drivers/block/ub.c David S. Miller
2004-06-26 21:56 ` drivers/block/ub.c Oliver Neukum
2004-06-26 22:07 ` drivers/block/ub.c David S. Miller
2004-06-26 22:36 ` drivers/block/ub.c Oliver Neukum
2004-06-26 23:20 ` drivers/block/ub.c David S. Miller
2004-06-27 4:31 ` drivers/block/ub.c Oliver Neukum
2004-06-27 6:34 ` drivers/block/ub.c David S. Miller
2004-06-27 10:42 ` drivers/block/ub.c Oliver Neukum
2004-06-27 21:26 ` drivers/block/ub.c David S. Miller
2004-06-28 14:15 ` drivers/block/ub.c Scott Wood
2004-06-28 20:25 ` drivers/block/ub.c David S. Miller
2004-06-28 20:48 ` drivers/block/ub.c Scott Wood
2004-06-28 20:58 ` drivers/block/ub.c David S. Miller
2004-06-28 20:50 ` drivers/block/ub.c Matthew Dharm
2004-06-28 20:59 ` drivers/block/ub.c David S. Miller
2004-06-28 21:01 ` drivers/block/ub.c Pete Zaitcev
2004-06-28 23:52 ` drivers/block/ub.c Matthew Dharm
2004-06-28 20:57 ` drivers/block/ub.c Oliver Neukum
2004-06-28 21:03 ` drivers/block/ub.c David S. Miller
2004-06-28 21:18 ` drivers/block/ub.c Scott Wood
2004-06-28 22:22 ` drivers/block/ub.c David S. Miller
2004-06-28 22:31 ` drivers/block/ub.c Scott Wood
2004-06-28 22:40 ` drivers/block/ub.c Roland Dreier
2004-06-29 1:54 ` drivers/block/ub.c Robert White
2004-06-29 2:15 ` drivers/block/ub.c David S. Miller
2004-06-29 2:49 ` drivers/block/ub.c Robert White
2004-06-29 18:31 ` drivers/block/ub.c Andy Isaacson
2004-07-05 10:01 ` drivers/block/ub.c Roman Zippel
2004-06-29 7:12 ` drivers/block/ub.c Vojtech Pavlik
2004-06-29 1:39 ` drivers/block/ub.c Robert White
2004-06-29 17:02 ` drivers/block/ub.c Kurt Garloff
2004-06-26 22:54 ` drivers/block/ub.c Andries Brouwer
2004-06-26 22:59 ` drivers/block/ub.c Oliver Neukum
2004-06-26 23:08 ` drivers/block/ub.c Andries Brouwer
2004-06-27 5:04 ` drivers/block/ub.c Oliver Neukum
2004-06-27 14:08 ` drivers/block/ub.c Andries Brouwer
2004-06-27 14:24 ` drivers/block/ub.c Oliver Neukum
2004-06-27 15:19 ` drivers/block/ub.c Alan Stern
2004-06-27 15:45 ` drivers/block/ub.c Andries Brouwer
2004-06-28 23:58 ` drivers/block/ub.c Jeff Garzik
2004-06-28 0:10 ` drivers/block/ub.c Pete Zaitcev
2004-06-28 16:01 ` drivers/block/ub.c Alan Stern
2004-06-27 15:23 ` drivers/block/ub.c Andries Brouwer
2004-06-27 16:11 ` drivers/block/ub.c Oliver Neukum
2004-06-26 22:46 ` drivers/block/ub.c Oliver Neukum
2004-06-27 3:52 ` drivers/block/ub.c Alan Stern
2004-06-27 4:05 ` drivers/block/ub.c Alan Stern
2004-06-27 5:02 ` drivers/block/ub.c Greg KH
2004-06-27 15:23 ` drivers/block/ub.c Alan Stern
2004-06-27 20:29 ` drivers/block/ub.c Pete Zaitcev
2004-06-27 21:03 ` drivers/block/ub.c Matthew Dharm
2004-06-28 15:40 ` drivers/block/ub.c Alan Stern
2004-06-28 16:42 ` drivers/block/ub.c Oliver Neukum
2004-06-28 19:50 ` drivers/block/ub.c Alan Stern
2004-06-27 5:35 ` drivers/block/ub.c Matthew Dharm
2004-06-27 15:28 ` drivers/block/ub.c Alan Stern
2004-06-27 22:56 ` David Brownell [this message]
2004-06-27 23:43 ` drivers/block/ub.c Pete Zaitcev
2004-06-28 15:05 ` drivers/block/ub.c David Brownell
2004-06-28 15:56 ` drivers/block/ub.c Alan Stern
2004-06-28 16:23 ` drivers/block/ub.c David Brownell
2004-06-28 16:46 ` drivers/block/ub.c Oliver Neukum
2004-06-28 17:13 ` drivers/block/ub.c David Brownell
[not found] ` <mailman.1088290201.14081.linux-kernel2news@redhat.com>
2004-06-27 23:57 ` drivers/block/ub.c Pete Zaitcev
2004-06-29 11:05 ` drivers/block/ub.c Jeff Garzik
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=40DF50A7.1020404@pacbell.net \
--to=david-b@pacbell.net \
--cc=arjanv@redhat.com \
--cc=greg@kroah.com \
--cc=jgarzik@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mdharm-usb@one-eyed-alien.net \
--cc=oliver@neukum.org \
--cc=stern@rowland.harvard.edu \
--cc=tburke@redhat.com \
--cc=zaitcev@redhat.com \
/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