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.
>
>
> 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.
> (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.)
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."
> Personally I like having two UHCI drivers, gives me a better test spread
> for my device drivers, but I might just be weird in that way...
Just think for a minute about what impact it would have if, for each
device supported by driver code in the kernel tree, we had two similar,
but different, drivers. Really, my mind boggles. How about yours?
I can only think of one device supported in the kernel tree that
currently has two drivers -- the AIC7XXX SCSI hardware. This is a
temporary situation where a new AIC7XXX SCSI driver has been introduced
into the kernel tree. The difference is that the decision to drop
the old driver and migrate to the new one has already been made.
The old driver will only linger until the new driver has gotten
extensive testing. If I understand this situation correctly, the
new AIC7XXX driver is being actively developed by the hardware
manufacturer in an open development process and the Linux SCSI
development community have already agreed that this new driver is
better code.
As for your desire to compare performance differences, et cetera:
I really prefer that everyone focus on tuning one driver by just
thinking really hard about how the code works, analyzing it and
studying and testing alternate patches to that one driver to
ascertain which patches make the most improvement. I think that
this is how the memory management development group does most of
its work. They just explore a lot of alternative approaches, but
they work from one code base. I think the most important thing,
IMVHO, is that the MM team tests a lot of patches that never make
it into the kernel tree. They stay somewhere in:
ftp://ftp.kernel.org/pub/linux/kernel/people/*
There, people toss ideas around and make things better. They don't
clog up the process for users or even other kernel developers.
If you, Georg and Johannes want to maintain private patches or
HCDs, even, to help you explore performance tweaking ideas, okay.
But, please, not in the main kernel tree. And, really, it makes
more sense to work from a common driver code base.
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.
Miles
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
