From: David Brownell on
On Wednesday 07 April 2010, Greg KH wrote:
> You should put a:
> ��������From: David Brownell <dbrownell(a)users.sourceforge.net>
> as the first line of the body of this patch, so it properly shows up as
> David's code.
>
> I also would like to get an ack from David that he doesn't mind his code
> moving into the kernel here (personally I think it's a good thing to be
> here.)
>
> thanks,

ISTR sending an ack .... but, not with a "From:" like that. I did author the
code, but the *patch* is not from me.


Omitting all the instructions and the test plan seems like a big mistake, too...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Brownell on
On Wednesday 07 April 2010, Michal Nazarewicz wrote:
>
> The testusb application can be used to test various USB gadget
> that implment the source/sink intrerface.

That comment is woefully incomplete. It's not just gadgets it exercises,
and a lot of thought went into testing streaming modes too (within limitations
of a the trivial test harness).

And more significantly ... It's part of a fairly complete test suite which exercises

- all four types of USB 2.0 data transfer,

on both peripheral and host sides

- - Good coverage of observed hardware and software failure modes,
(to help ensure routine fauilts are handled well)

- Decent coverage of Linux-USB programmming interfaces ... both
in-kernel and user-visible.

- - Stress test modes

For more info, whvih *SHOULD* be referenced from wherever the
kernel tree includes any of this code:

See: http://www.linux-usb.org/usbtest/

Just throwing tools at someone without instructions can be rather
counter-productive .... they get misused, important issues ignored,
results mis-interpreteed, etc.

Note that there's a basic test plan, letting folk put
drivers (and hardware) through their paces. THe evidence is that when
drivers behave on that whole suite, Linux won't misbehave much at all.

In fact, without such tools and a test plan, it'd be hard to have mch faith
in the drivr quality ... except as a weak and scattershot "this combination of
drivers and hardware seems OK for now".
futile


At one point there were allegedly folk working on Linux testng frameworks, but
they never seem to have looked at this (even on specific request); I'm not sure
if it was just general weakness in driver testing efforts (they're not easy to test),
lack of background (/interest?) in USB, or something else. (As many of us know, it's
a sad truth that testing isn't all that glamorous, for all that it's essential).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/