I'd like to add a few comments to this, but first
I want to apologize to Miles for some of my comments
yesterday. I didn't follow all of his statements,
but I agree with his conclusion.
I'd like to see this settled (solved) in a way that is
best for Linux, USB, and Linux-USB users, and developers,
and I'm fairly sure that JE agrees with that.
I'd prefer that selecting one UHCI HCD not be an
arbitrary decision, but that's not my decision to make.
I also agree with David Johnson that USB device driver
developers should be able to expect consistent behavior
from any/all of the HCDs. It seems to me that we have
discussed this a few times in the past.
When JE's uhci (alt-JE) HCD has bulk queueing and
PCI alloc consistent support (JE's own, or David's
pci_pool patch), it could easily be the one to choose.
(more)
> -----Original Message-----
> From: Miles Lane [mailto:[EMAIL PROTECTED]]
>
> Greg KH wrote:
>
> > On Thu, Mar 15, 2001 at 09:58:22PM -0800, Miles Lane wrote:
> >
> >> We should go through some formal decision process, rather than
> >> deciding to use uhci just because its kinks are worked
> out. The other
> >> factors should be weighed before we make our choice.
The criteria that you (Miles) listed are basically the ones
that I used for several months, along with at least one more,
which could be worded in many ways (examples):
. which driver uses the kernel API more appropriately
or
. which driver is more "Linux-like"
or
. which driver abuses interrupts less
In any case, that list of criteria wasn't sufficient to make
a decision. (repeating) We need HCDs that provide consistent
behavior for USB device drivers.
> > If you remember the last time we tried to do this, I kept a tally of
> > everyone's testing reports, which drivers worked with which, what
> > different speeds were, and lots of other things. I tallied them,
> > reported them, and then...
> >
> > In good open source spirit we threw it all away and said
> "who cares, let > > the user decide." :)
>
> Whoops. Wrong decision.
Without getting personal about it, I think that the wrong
decision was to ever add a second one. [Then we can debate
which one was the "second one." :]
However, in an open source world, there is always the
possibility that someone will/can come along and do
something better or faster than what's already there.
We have to accept that.
For example, if Roman and David cooked up a UHCI HCD
that worked exactly like the OHCI HCD as far as USB
device drivers is concerned, and it offered better
performance at the same time (by using a pool of TDs
per endpoint and rotating them, without dynamic allocation
on each transfer), then it should be a winner.
> > (actually neither driver was "better" than the other, they
> both worked
> > differently, causing some devices to only work with one,
> some with the
> > other, and most with both. So the decision was an easy one.)
That's right. There was no winner.
> Respectfully, I think this decision may have made sense at the time,
> but it's time to stop wasting development time, testing time and
> user's time. I have seen many messages from users saying, "Hey,
> my device XXXXX doesn't work with UHCI HCD XXXXX." To which someone
> responds, "Try the other UHCI driver." This usually satisfies the
> user. But what if we get a user with two devices and neither
> HCD supports both devices? Let's face it, users should not have
> to think about this stuff. In fact, everything should "just work"
> and user's should never have to write to us. Our response shouldn't
> be, "Oh, use the other driver." It should be, "Drat, let's fix that
> so noone else has to write in about that bug."
Agreed.
[snip]
> One last problem with having two equal but different code bases
> is that borrowing a good idea from one implementation may not
> be very straightforward. So we wind up not really benefitting
> very much from the comparison. In other words, users don't get
> one best driver to use, they get two drivers that act a bit
> differently and, under the hood, work quite differently.
I think that this is a potential problem for developers to
grapple with, and possibly could be done better outside the
kernel tree, as you suggested.
~Randy
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
