David Brownell wrote:
> 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?
Although I am not an HCD developer, I'll hazard an opinion --
I think we should fork. I'd prefer to see the HCD developers
keep the current drivers stable and improve them as we take the
forked drivers through a period of massive overhaul and
instability. I believe this approach would allow the folks
who are working on on the shared code drivers to move forward
much more rapidly, due to the fact that they wouldn't have to
worry about destabilizing production drivers. I think it is
imperative that we get the shared-code drivers ready as quickly
as possible. I don't think you'll have much trouble getting
testers to volunteer. Count me in.
> 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.
Well, are you thinking the new code will require much change in
the other drivers? I have been thinking that the differences
would be hidden to the device drivers. If there will be lots of
changes that will be visible to device drivers, perhaps the
incremental approach makes more sense. It does still seem
that a forked code base could absorb more radical changes quickly,
which could be followed by a testing/fixing cycle.
Cheers,
Miles
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
