linux-kernel - Re: [PATCH] [USB] UAS: Achitecture; TMF; more

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: <87456.32791.qm@web31801.mail.mud.yahoo.com>
Date:	Fri, 5 Nov 2010 23:52:00 -0700 (PDT)
From:	Luben Tuikov <ltuikov@...oo.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	Matthew Wilcox <willy@...ux.intel.com>
Subject: Re: [PATCH] [USB] UAS: Achitecture; TMF; more

--- On Fri, 11/5/10, Greg KH <greg@...ah.com> wrote:
> > This patch changes 86% of the driver. More is to come,
> but this is
> > a self-contained patch so it can be applied.
> 
> No it can not at all, sorry.

Greg, would you accept a brand new driver, say uastoo.c (just like
8139too.c came about, remember?), or would you say "This is 14% the same
as uas.c, and thus cannot go in"?

Is 14% difference too much or too little?  Surely, the sum of
small tiny individual patches, *would* replace 86% of the driver. BTW,
there are more things to fix even on top of that.

(I wonder how much similar 8139too.c was to rtl8139.c... when 8139too.c
got in back about 10 years ago? I bet it was more than 14%. Hey, I'm building precedent here.)

Or would you say "only individual patches even if it changes 100% of the
code".

> Remember, patches do one single thing at a time.

I wholeheartedly agree. One thing at a time. Self-contained, well defined. 

I really did want to do that with uas.c but it was really hard. I was
like "where to begin?"  There was no one single change to say "here it
is" without changing something else.

> This patch is equivalant to deleting the file and replacing it with a
> totally different driver, which is unacceptable.

I did want to submit them one at a time. I really did. But one change
necessitated another in order to keep things consistent, and it ended
up like this, one single commit in my git tree.

I really do have one single commit as this "patch".  I really did want
to submit it as individual one at a time. But there was no well defined "one at a time".

> Please break all of these changes up into individual
> patches and resubmit them.  That's the only way we can take
> them.

That, or a new driver perhaps?
The net effect of individual patches would be the same, leaving only
14% of the code the same and maybe less with the more work pending.
Perhaps a new driver acknowledging it is based on this one FWIW?

> I also suggest you go re-read Documentation/development_process/ as well.

Did Willy reply to your query about the previous patches? I didn't see
his reply.

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