From: Pete Zaitcev <zaitcev@redhat.com>
To: David Brownell <david-b@pacbell.net>
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, zaitcev@redhat.com
Subject: Re: drivers/block/ub.c
Date: Sun, 27 Jun 2004 16:43:27 -0700 [thread overview]
Message-ID: <20040627164327.06b74845@lembas.zaitcev.lan> (raw)
In-Reply-To: <40DF50A7.1020404@pacbell.net>
On Sun, 27 Jun 2004 15:56:39 -0700
David Brownell <david-b@pacbell.net> wrote:
> > +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?
I do not care for the runtime overhead with ub. It might as well be
written in Java, copy every byte with get_user, and take a context
switch on every byte as long as it's bug free. Throwing SCSI away
throws away SCSI bugs (which are few, thanks jejb!), but also throws
away problems with interfacing to SCSI and sd.
Also, private SCSI stack allows to mimic Windows as closely as we can.
Want 36 byte inquiry? No problem! Want to ban START STOP UNIT? Be my
guest! With any luck, we'll be able to get by without anything like
unusual_devs.h (yes, I know it won't happen, but it's the ideal).
Custom error processing is a help as well. Currenly usb-storage
attempts to make SCSI eh to do the right thing by pulling very
thin threads. It is an excessively roundabout way to do things.
Performance is not a goal here. In some cases, ub might end marginally
faster than usb-storage, if only because it uses no worker thread, but
it's purely by accident.
> > + /*
> > + * 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? :)
There is no way to submit a URB and give page, offset, length as arguments.
Three ways to accomplish a similar result exist currently:
0. Use bounce buffers and submit with kernel virtual address as argument.
1. Map everything yourself with "generic" DMA, then use URB_NO_TRANSFER_DMA_MAP.
This includes reading the DMA mask from the controller device, and falling
back if it is zero.
2. usb_sg_wait, which takes sg list but does not allow to submit anything
and must be called from a process.
Regardin #2 you say that ``that code isn't "very fresh and buggy", having
been in use with all USB-Storage devices for over a year and a half'' and
yet I observe that fairly serious fixes were applied just this week. What
passes muster with usb-storage is nowhere near the standard which Havoc
gave me mandate to reach and where ub shoots.
The hacking required to create usb_sg_submit() and have it sharing the
backend with usb_sg_wait is conceptually trivial. But it must be a
separate project. If it were started a year ago then I'd be happy to use
that API now. As it is, no way.
The #1 is a possibility, but it requires a little extra coding.
-- Pete
next prev parent reply other threads:[~2004-06-27 23:43 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 ` drivers/block/ub.c David Brownell
2004-06-27 23:43 ` Pete Zaitcev [this message]
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=20040627164327.06b74845@lembas.zaitcev.lan \
--to=zaitcev@redhat.com \
--cc=arjanv@redhat.com \
--cc=david-b@pacbell.net \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.