svn commit: r257200 - in head/sys/arm: allwinner allwinner/a20 arm at91 broadcom/bcm2835 econa freescale/imx include lpc mv rockchip samsung/exynos tegra ti ti/am335x ti/omap4 ti/twl versatile xili...

Ian Lepore ian at FreeBSD.org
Sun Oct 27 19:19:16 UTC 2013


On Mon, 2013-10-28 at 04:01 +1100, Bruce Evans wrote:
> On Sun, 27 Oct 2013, Ian Lepore wrote:
> 
> > Log:
> >  Remove #include <machine/frame.h> from all the arm code that doesn't
> >  really need it.  That would be almost everywhere it was included.  Add
> >  it in a couple files that really do need it and were previously getting
> >  it by accident via another header.
> 
> Oops, I complained too soon about style bugs attached to these includes
> in another reply.  Removing the includes also removes most of the
> collateral style bugs.
> 
> How do you find the files that _really_ do need it?  Nested pollution
> makes this difficult.  tools/kerninclude barely works.  When I tried
> to reduce nested pollution, I used a predecessor of tools/kerninclude
> that was more usable because it was more localized, but it got other
> things wrong.

Mostly by brute force and a fast machine for compiling.  I removed it
from pretty much everywhere it appeared except the few places I knew
were legit (such as arm/trap.c), then added it back as needed to get a
clean compile.  At one point I realized that a place where it was
included from within another header was really required[1] and I had to
backtrack a bit, do that, then re-iterate forward.  Luckily that didn't
happen until most of the arm tree had compiled without frame.h being
included from any other .h.  I've had this brute force method break down
completely with more complex situations, but it went pretty quickly with
this one.

[1] Really required given the way other code is structured now.  There's
a macro in cpu.h that expands to derefence trapframe, and that macro is
used in kern/something.c.  Maybe that macro could be a function, but I
didn't want to sidetrack and review the performance implications of that
change at the time.

-- Ian




More information about the svn-src-head mailing list