From: Pete Zaitcev <zaitcev@redhat.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Wolfgang Scheicher <worf@sbox.tu-graz.ac.at>,
linux-kernel@vger.kernel.org, zaitcev@redhat.com
Subject: Re: 2.6.9 USB storage problems
Date: Thu, 4 Nov 2004 12:14:32 -0800 [thread overview]
Message-ID: <20041104121432.64d2d7fc@lembas.zaitcev.lan> (raw)
In-Reply-To: <Pine.LNX.3.96.1041104135949.12155B-100000@gatekeeper.tmr.com>
On Thu, 4 Nov 2004 14:04:58 -0500 (EST), Bill Davidsen <davidsen@tmr.com> wrote:
> > I thought about the coexistence between the two at some length, and it seems
> > to me that the current scheme is the simplest workable scheme. I even thought
> > it as "least confusing" until messages from Wolfgang and others made it clear
> > that relationship between ub and usb-storage is not obvious enough to them.
> > I'm always open to patches, too.
>
> It would seem that wanting to use both flash keys and more common USB
> devices would be the common case for those who use flash keys at all.
> Would it be possible to have the regular USB drivers support the slow
> devices, if only to the extent of handing them off as they do CD, NIC, or
> disk? Or are these slow devices so unique that they are totally
> incompatible with faster devices?
It's not a question of speed, in my view, but rather the protocol.
I have a patch by Peter Jones in my queue, which allows to burn CDs
with ub, for example. But splitting a whole protocol class is difficult.
It would be great to give DVDs to usb-storage and keep hard drives
and flash keys to ub, but I don't see a good way to accomplish that.
Again, if you come up with a patch which does inquiry and somehow
arranges who handles what, it may be a good thing. But it has to pass
a test of "not introducing too much complexity for too little gain".
I understand that I am setting a situation of two drivers doing similar
thing but not quite in the same way, just like in the bad old days
of uhci and usb-uhci. My current goal is to allow all users to have ub
configured at all times, if they want to. If it didn't fail devices like
Fabio's and if burned CDs, you'd never notice that something was different,
right? If this turns out unattainable, we can always remove ub from
the tree.
-- Pete
next prev parent reply other threads:[~2004-11-04 20:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-12 12:24 2.6.9-rc4 " Wolfgang Scheicher
2004-10-12 17:51 ` bert hubert
2004-11-01 17:50 ` 2.6.9 " Wolfgang Scheicher
2004-11-01 19:10 ` Matthew Dharm
2004-11-01 19:40 ` Wolfgang Scheicher
2004-11-01 21:35 ` Matthew Dharm
2004-11-01 22:19 ` Wolfgang Scheicher
2004-11-01 23:33 ` Pete Zaitcev
2004-11-02 0:46 ` Pete Zaitcev
2004-11-03 22:02 ` Bill Davidsen
2004-11-04 9:19 ` Pete Zaitcev
2004-11-04 19:04 ` Bill Davidsen
2004-11-04 20:14 ` Pete Zaitcev [this message]
2004-11-02 2:50 Chuck Ebbert
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=20041104121432.64d2d7fc@lembas.zaitcev.lan \
--to=zaitcev@redhat.com \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=worf@sbox.tu-graz.ac.at \
/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®