On 16 Mar 2001 08:31:16 -0800, Dunlap, Randy wrote:
>
> 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.
No problem and thanks.
> 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.
Agreed, but I'd like to hear from Johannes whether he agrees
that having just one UHCI driver is the way to go and what
selection process he intends to use. Johannes?
> > -----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
Well, this all sounds good to me.
> 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.
That's why David and Roman's desire to share as much code as is
possible, practical and useful makes a lot of sense to me.
Of course, this presupposes that the hardware (UHCI, OHCI, EHCI)
allows for common behavior. If I understand correctly, this
isn't too much of a problem and the major differences between USB
host-controller types are only slight performance differences
(in the case of EHCI, I am referring to the backward compatibility
slow-speed mode). Is that correct?
> > > 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.
Yeah. Please, noone take my desire to have only one driver in
the tree as a criticism of anyone building new, redundant drivers.
If you all can build a better mousetrap or HCD, as the case may
be, please do. I'd just advocate the USB community agreeing to
migrate to demonstrably better drivers whenever they become
available and to jettison older drivers as soon as is practicable
after the new, better drivers are introduced into the kernel tree.
> 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.
Agreed. I'd like to see this be an ongoing effort as part of the
2.5 development process. Hopefully, a lot of this work will be
backported to the 2.4 tree, as well. 2.4 is going to be hanging
around out there for a _long time_.
BTW, has anyone given any thought to how much code we'll be
backporting to the 2.2 series kernel after the 2.5 tree opens
up?
Thanks,
Miles
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
