linux-kernel - Re: [PATCH 7/8] USB: testusb: imported David Brownell's USB testing application

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <op.va5kmrtr7p4s8u@pikus>
Date:	Wed, 14 Apr 2010 14:50:41 +0200
From:	Michał Nazarewicz <m.nazarewicz@...sung.com>
To:	David Brownell <david-b@...bell.net>
Cc:	linux-usb@...r.kernel.org, Peter Korsgaard <jacmet@...site.dk>,
	Rupesh Gujare <rupeshgujare@...il.com>,
	linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 7/8] USB: testusb: imported David Brownell's USB testing
 application

> 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.

On Wed, 14 Apr 2010 11:41:47 +0200, David Brownell <david-b@...bell.net> wrote:
> 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).
>
> 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,
> - decent coverage of Linux-USB programming interfaces, and
> - stress test modes
>
> For more info, which *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
> much faith in the driver 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 testing
> 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.

Let me start with explaining that my original intent was not to get the
testing code to the Linux kernel and thus I limited documentation to
minimum.  I just wanted to put some code that may be used to test the
FunctionFS out into the air so that anyone who stumbles across the
patchset can test the FunctionFS code even though the test code may be
not inside the mainline kernel.

However, if Greg thinks it might be a good idea to put some testing code
into the tree, then it's fine by me.  This may even lead to more testing
tools be submitted and maybe after some time an unified testing framework
may emerge.

Bottom line is, if community (represented by the maintainer ;) ) wants the
patches in the kernel, then let them have it!

Obviously, the higher the quality patches are the better, so all the constructive
criticism is welcomed.  Thus I accept your comments and agree with them.  What
I'd like to ask though is what you are proposing?

Should I put a short comment saying this file is part of a greater test suite
with a link to the linux-usb.org/usbtest site?  Or maybe more code and/or
documentation should be included in the kernel?  Or maybe the whole idea of
including this code in the kernel was not so good?

I'm happy either way so I'd like to do what's the best for Linux and community
thus am asking for your comments (and I mean "your" as in plural :) ).

> On Wednesday 07 April 2010, Greg KH wrote:
>> You should put a:
>>         From: David Brownell <dbrownell@...rs.sourceforge.net>
>> as the first line of the body of this patch, so it properly shows up as
>> David's code.

On Wed, 14 Apr 2010 11:30:52 +0200, David Brownell <david-b@...bell.net> wrote:
> ISTR sending an ack .... but, not with a "From:" like that.  I did author the
> code, but the *patch* is not from me.

Do you think a commit with me as an author and a clear indication in the
message that it imports your code would be better?

-- 
Best regards,                                           _     _
  .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
  ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
  ooo +---[mina86@...a86.com]---[mina86@...ber.org]---ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/