linux-kernel - Re: [PATCHv1 000/211] unicore32 architecture support

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: <201012101316.49153.arnd@arndb.de>
Date:	Fri, 10 Dec 2010 13:16:48 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Tejun Heo <tj@...nel.org>,
	Guan Xuetao <guanxuetao@...c.pku.edu.cn>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv1 000/211] unicore32 architecture support

On Thursday 09 December 2010, Thomas Gleixner wrote:
> Crap. a single patch is a major PITA for review. It's even worse than
> 211 per file patches.

It doesn't matter which way is worse than the other. Both are
impractical for people to look at and not helpful.

> It's ok to have several patches ordered by topics
> 
>   - generic header stuff
>   - processor and system headers
>   - low level entry and setup code
>   - process/thread related code
>   - mm related code
>   - timers
>   - interrupts
>   - ptrace
>   - signals
>   - fault handling
>   - misc
>   - build system, main makefile, Kconfig
> 
> That makes it actually feasible to review.

Agreed.

One important step is to send patches that touch existing
architecture independent code separately from new files
that depend on the changes.

In some cases, it's also useful to send out less than the
complete set of patches at a time, but only if it is possible
to understand the patches that did get sent by themselves.
For instance, don't send a device driver implementation but
not the header files that defines the user interface and the
hardware registers.

My personal upper bound would be on the order of ten large
patches or (alternatively) twenty small patches. The size of
the individual mails often varies a lot and that's fine.
A patch containing 100kb of register definitions may be
easier to review than a one-line change in an important
place.

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