I've already put some thought into one item from Greg's list:

> - try to incorporate some of the HCD code into a common chunk to
>   make the HCD drivers a bit simpler (like has been proposed.)

Also, have fewer hcd-specific bugs ... because likely 1/3 or more
of the hcd code can be shared between all those drivers!   (I heard
one estimate of 2/3, that seems unlikely to me.)  IMO that's a strong
argument on the code support side.

This raises the question of how to make that happen.  It'll involve
changes to the OHCI and UHCI drivers.  There are two basic
ways to do that:  fork the drivers, or incrementally evolve each
one (preserving "full functionality" at all times, modulo the bugs).

So one question I have:  Fork, or Evolve?

A less fundamental one is how to package that sharable/common
chunk of code.  I've already structured EHCI so there's a line
between that sharable stuff (richer "struct usb_bus" level support)
and the main driver.  That particular line will have to evolve from
what was in my March 5 snapshot ... but, how?

I think I'd probably prefer an evolutionary approach, adding a
new "drivers/usb/hcd.c" module and growing usb_bus and
usb_operations structures directly.  It could easily start with
root hub or PCI infrastructure code.  Such incremental growth
would make it easier for folk to understand the changes as they
happen, and likely make it easier for more folk to help out.
Should make it easier to merge into 2.4 based systems too.

That's not how the EHCI code is currently packaged, though
root hub and PCI code are certainly parts I hope would be
shared ... as well as (later) bandwidth scheduling code.

Comments?

- Dave







_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to