Review request: sparse CPU ID maps
Nathan Whitehorn
nwhitehorn at freebsd.org
Tue Jul 5 18:26:53 UTC 2016
On 07/03/16 13:11, Warner Losh wrote:
> On Sun, Jul 3, 2016 at 1:37 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> On 2 July 2016 at 17:08, Nathan Whitehorn <nwhitehorn at 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
>
That sounds like the right approach. Since the original patch fixes bugs
in 11, rather than niceties, I will send it to re@ tomorrow. After the
branch, I'll do a sweep of other obviously wrong code for 12 with an MFC
timer.
-Nathan
More information about the freebsd-hackers
mailing list