Date: Sun, 3 Jul 2016 14:11:00 -0600 From: Warner Losh <imp@bsdimp.com> To: Adrian Chadd <adrian@freebsd.org> Cc: Nathan Whitehorn <nwhitehorn@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, outro pessoa <outro.pessoa@gmail.com> Subject: Re: Review request: sparse CPU ID maps Message-ID: <CANCZdfpJJLoKxB-ZdMRQyHq9eT1uihg4UGeBvRgBEOOC1pt_Yg@mail.gmail.com> In-Reply-To: <CAJ-Vmon4kRNc5LiwibtiPi_FQ1v5w_MQEjP%2BOfcC7J74iTKs0A@mail.gmail.com> References: <57761101.3030101@freebsd.org> <CAD9=5Xw-MmVVSSo6nRvSRvGaLbd1Z1YRyVKyF9JfmucNKMGBZg@mail.gmail.com> <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org> <CAJ-Vmon4kRNc5LiwibtiPi_FQ1v5w_MQEjP%2BOfcC7J74iTKs0A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 3, 2016 at 1:37 PM, Adrian Chadd <adrian@freebsd.org> wrote: > On 2 July 2016 at 17:08, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: >> A reasonable first pass at checking for this kind of bug is doing grep -lR >> '< mp_ncpus'. Running that on sys/arm and sys/arm64 shows the following >> files: >> arm/mv/armadaxp/armadaxp_mp.c >> arm/include/counter.h >> arm/broadcom/bcm2835/bcm2836.c >> arm/broadcom/bcm2835/bcm2836_mp.c >> arm/freescale/imx/imx6_mp.c >> arm/allwinner/aw_mp.c >> arm/rockchip/rk30xx_mp.c >> arm/amlogic/aml8726/aml8726_mp.c >> arm/samsung/exynos/exynos5_mp.c >> arm/arm/mp_machdep.c >> arm/nvidia/tegra124/tegra124_mp.c >> arm64/include/counter.h >> arm64/arm64/gic_v3.c >> arm64/arm64/gic_v3_its.c >> arm64/arm64/gicv3_its.c >> >> All of them should, in some sense, be CPU_FOREACH(), but it may not matter. >> For example, it may not be possible to have sparse CPU IDs on some or all of >> those SOCs. At least the generic ones (counter, mp_machdep.c, gic (why are >> there both gic_v3_its.c and gicv3_its.c?)) should be changed, I think. >> -Nathan > > I think converting all the users over to the CPU_FOREACH thing is the > right way to go, even if the SOC doesn't require it. People do bring > up new systems by copy/pasta'ing an existing similar system, so we're > best served by having all the consumers migrated. > > But, I'd do it in head/12. Early in head/12. :-P It is a mergeable change too, since it wouldn't change any APIs. At least the conversion to CPU_FOREACH. We don't want too many sweeping changes that can't be merged too early (that way leads to lots of maintenance issues), but we can do something like this. Merging would be optional, but possible, for those bits of the tree that need it. Though, for something like this, there's little against doing a full merge and a lot for it... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpJJLoKxB-ZdMRQyHq9eT1uihg4UGeBvRgBEOOC1pt_Yg>