* Kees Cook <keesc...@chromium.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
