linux-kernel - Re: [PATCH 7/8] USB: gadget: g

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] [day] [month] [year] [list]

Date:	Fri, 21 May 2010 12:13:32 +0200
From:	Michał Nazarewicz <m.nazarewicz@...sung.com>
To:	David Brownell <david-b@...bell.net>, linux-usb@...r.kernel.org
Cc:	David Brownell <dbrownell@...rs.sourceforge.net>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/8] USB: gadget: g_multi: more configurable

>> Added Kconfig options for each
>> function used by g_multi so that
>> one can customize the gadget to a greater extend.
>>
>> Note that it will be wise to change vendor and product ID

On Thu, 20 May 2010 18:22:54 +0200, David Brownell <david-b@...bell.net> wrote:
> For the record .... I would *MUCH* rather see new gadgets than
> pursue this path of tweaking/customizing existing ones and thus
> removing/changing behaviors folk may rely on.

The problem with this approach is that if you have 4 USB functions you
can came up with 16 different gadgets (and that does not take into
consideration order of functions but lets ignore that).

A fully customizable gadget may let one tweak it and when he finally
settles for a set of functions develop a custom gadget (for instance by
hacking off parts of the g_multi).

I don't really expect g_multi will be widely used in its base form.  Most likely,
it will be hacked and slashed for one's needs so why not make it simple to do?

> Tweaking is OK during certain development stages, but when it comes
> to production, there should be a single version of the gadget driver
> which isn't especially dependant on Kconfig options.  It should act the
> same at all times.

On Thu, 20 May 2010 18:30:47 +0200, David Brownell <david-b@...bell.net> wrote:
> Note that g_multi was intended to be a a fairly simple example,
> so another reason I don't like seeing all those config options
> is that it would no longer be a simple example ....

To be honest it was never my intend. :)  As a matter of fact, I'm
working on other features to add to g_multi, most notably at the
moment an "Install Mode" or "NoCD" mode.

In the end, I'd like to turn g_multi into a full flagged run-time
customizable composite gadget similar to Android's composite (except
better ;) ) so that one would be able to build her own composite
gadget in a matter of seconds without the need of calling all the
setup, cleanup, bind, etc. functions herself.

> I see you did a bunch of good work on MS-Windows interop (yay!),
> but that can be done without complexifying this driver.  Let some
> other (new) driver take that role of "complex example"), but keep
> the simple one so there's an easy approach to the easy concepts.

All in all, if I understand your point correctly, you have only
issue with the 7th patch which introduces Kconfig options.  All the
other patches seem OK, or do you have some comments on those as well?

-- 
Best regards,                                        _     _
| Humble Liege of Serenely Enlightened Majesty of  o' \,=./ `o
| Computer Science,  Michał "mina86" Nazarewicz       (o o)
+----[mina86*mina86.com]---[mina86*jabber.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/