Date: Sun, 27 Oct 2013 13:19:06 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: 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... Message-ID: <1382901546.1170.236.camel@revolution.hippie.lan> In-Reply-To: <20131028030951.V929@besplex.bde.org> References: <201310270134.r9R1YBbI037760@svn.freebsd.org> <20131028030951.V929@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1382901546.1170.236.camel>