linux-kernel - Re: GRU driver feedback

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]

Date:	Thu, 24 Jul 2008 08:52:34 +0200
From:	Nick Piggin <npiggin@...e.de>
To:	Jack Steiner <steiner@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: GRU driver feedback

On Wed, Jul 23, 2008 at 10:26:28PM -0500, Jack Steiner wrote:
> On Wed, Jul 23, 2008 at 04:12:30PM +0200, Nick Piggin wrote:
> > 
> > Hi Jack,
> > 
> > Some review of the GRU driver. Hope it helps. Some trivial.
> 
> Thanks for the feedback. I'm at OLS this week & barely reading email.
> I'll go thru the comments as soon as I get home next week & will
> respond in detail then.

OK, no problem. Andrew said he's happy to hold off the driver merge
for a bit and we should be able to drop it in post-rc1 if we can get
it sorted out.


> > - I would put all the driver into a single patch. It's a logical change,
> >   and splitting them out is not really logical. Unless for example you
> >   start with a minimally functional driver and build more things on it,
> >   I don't think there is any point avoiding the one big patch. You have to
> >   look at the whole thing to understand it properly anyway really.
> 
> I would prefer that, too, but was told by one of the more verbose
> kernel developers (who will remain nameless) that I should split the code
> into multiple patches to make it easier to review. Oh well.....

I don't want to make a big stink out of it. But I don't understand
why half (or 1/5th) of a driver is a particularly good unit of change.
1. basic functionality, 2. more stuff, 3. documentation, 4. kconfig or
some such splitup seems more appropriate if it really must be split,
but IMO each change should as much as possible result in a coherent
complete source tree before and after.

Anyway, yeah, no big deal so if Andrew decided to merge them together
or leave them split, I go along with that ;)

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