Greg KH wrote:
> From now until July 1, ...
>
> Let me (and the linux-usb-devel list) know about any thoughts you have
> pertaining to liking one of the drivers over the other one. Speed
> tests, size tests, code pretty tests, comment spelling tests,
> documentation tests, you name it, I want to know about it.
>
> ...
I confess I've not done much real UHCI testing, but I did do a bit
of basic code analysis (object and source) against versions of the
UHCI HCDs in the 2.5.22 kernel.
- The "uhci-hcd" driver is about 10% larger than "usb-uhci-hcd"
in terms of object size (even after disabling the /proc/driver
code!) ... and both are significantly larger than the OHCI and
EHCI drivers. Counting code+data+bss:
21337 uhci-hcd
19308 usb-uhci-hcd
17936 ehci-hcd
14091 ohci-hcd
On a pure object-size basis, "usb-uhci-hcd" wins here.
- Given the basic similarities between all that hardware (the only
"big" thing that needs to differ much is scanning the HC lists
to collect finished transactions), I think both UHCIs can very
likely be trimmed down further: the known differences can't
account for that much of a size difference. (EHCI is a bit more
complex than UHCI ... by rights, it should be the fattest HCD!
I heard MSFT's is over 100KBytes ... :)
- Only "uhci-hcd" has any BSS at all -- two words. One of those
words is a bug: "errbuf" should be HCD-private, not shared
between drivers, or should be protected by a driver-global lock.
(Likely not dangerous, and affecting only SMP today.)
(All have the same amount of initialized data.)
- Comparing source size, the two UHCIs are about the same in terms
of bytes, but "uhci-hcd" has more lines ... with many of them
being "non-functional" /proc/driver support. Given the object
code results above, that suggests more whitespace or comments.
I don't think either is compellingly better at commenting, though
it's nice to have some text in "uhci-hcd" describing locking
strategy. (Those are paired with cryptic "P:" comments, evening
things out ... :)
- It's hard to see (and compare!!) internal structure in "uhci-hcd"
since it doesn't split out memory and HC queue primitives in different
source files: it's all merged with the higher level glue.
- I see that "uhci-hcd" added some big-endian support. Has anyone
had a chance to test that? (Like on a PPC box.) I know that the
big-endian support on "usb-uhci(-hcd)" has been around for a very
long time now.
I'll send along some less general comments about the code later.
- Dave
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
