Date: Sat, 16 Apr 2016 11:00:25 +0200 From: Ingo Molnar <mingo@...nel.org> To: Kees Cook <keescook@...omium.org> Cc: Yinghai Lu <yinghai@...nel.org>, Junjie Mao <eternal.n08@...il.com>, Josh Triplett <josh@...htriplett.org>, Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Matt Redfearn <matt.redfearn@...tec.com>, "x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Vivek Goyal <vgoyal@...hat.com>, Andy Lutomirski <luto@...nel.org>, lasse.collin@...aani.org, Dave Young <dyoung@...hat.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v5 07/21] x86, boot: Fix run_size calculation * Kees Cook <keescook@...omium.org> wrote: > > So can we rename it to something more expressive, such as kernel_total_size or > > so? > > You got it. Thanks again for digging through all this! You are welcome! A couple of logistical suggestions: Could you please split up the series a bit and limit the next series to say no more than around 5 patches? (Can be a little bit more when justified to finish up a particular line of thought) That way I can apply them in reviewable groups, without having to reject the whole series because some patch deep into the series has some problem. I'd suggest starting with absolutely critical fixes (if any!) as-is, to make backporting easier. By the looks of it I don't think there's any such patch in this series, but just in case there are any, they can be at the front. Then come the various cleanup patches and non-critical fixes - everything that is not supposed to change the behavior of the kernel. I'd suggest doing them in roughly this order: - file renames first - so that any later revert in a smaller patch does not have to go through a rename barrier. - then .o-invariant trivial cleanups, the fixing, harmonization (and creation ;-) of comments. - then come more involved cleanups like moving logic from build time to boot time, stricter bounds checks, non-essential fixes, etc. It might be useful if you declared at this stage that you are mostly done with the preparatory work and that the code base is ready for heavier changes, so that people (and me) can review the whole source for anything missing. Often a car needs a good power wash before we can tell what body work is needed. ... and once we are happy and proud about the code base, then come the more exciting things: more fundamental changes, and new features - on top of a squeaky clean code base. This all can happen pretty quickly, as long as the ordering is proper. Thanks, Ingo
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.