From owner-freebsd-hackers@freebsd.org Sun Jul 3 20:11:01 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4F26B9055E for ; Sun, 3 Jul 2016 20:11:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C8FC20BC for ; Sun, 3 Jul 2016 20:11:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id f6so14268444ith.0 for ; Sun, 03 Jul 2016 13:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/qpGdDeYnkbKhUu/2jW0D/26XASzkXIAXyt6OyfN9yc=; b=KqshAoCtzHR4UgEwmVQU7WNVDhIp4DiB/LOzsM3e2mL4Vgbn9AEAMF0i6/TBpJ8v1N kTibrhgut9PhReo641/VDtyHIQ7NoqupHlK0EVAkNUXevPJIO3Z3yYDblA/d29y9oS3C eEoYwkY4jWb2BIiXyVjJ9/E8gMjJgLrTwF6PdLhKKN77Yn7zPkY7IqIVdINn+4FtCjG8 PFtRbGUUWmVvP+8v3sG95THfg/TqvFD2TgEDQYGQoCk+y+URT/JUZwq4kGZFR3+fenTu geu+i1UG9venGzwW3ZQsneK2AjI5dYLDz0S4vHBXzYsG+F/EOx9YKuQjVjY3Dhs6Pzsy FGHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/qpGdDeYnkbKhUu/2jW0D/26XASzkXIAXyt6OyfN9yc=; b=fwmk7cRNNpGzSEeQWRnoZlV7XdgpN4Qf6F5mZvwbfKVk4zRIxjK4Ms8YJ4npI+7kIt 0+/QiB7qmJk2kj8oovaHIYYzPZshfSGR/YLinJG366HGD5B/78cLIm54a4rXgsne7s47 GXUySfqUgz0oGBI7Si3Go3jQuVTScNVcD97aOgwaAnRb9QAcHmcfq5FPavUUoCllCgPM mdrUZflvdetREw6GOjjAyw0jVjT0hhoSwFmVVzs8t6/Chp7wGX6VA7dUL+S3e4YFSxpk O3rhywqfs4TVSwDqh+DHEjhoOPE3EBzfveoYMznWLQEHI16tJT6hJQRTt05N83fhsdIx Uarw== X-Gm-Message-State: ALyK8tIBj97vpcdC/5CFnStUU24/dfh53uWj9+wyu/xmv7RMnt2PBv64GlFq/rHWY67GwZZMJQRwxQZbNYAnxw== X-Received: by 10.36.41.16 with SMTP id p16mr7184342itp.60.1467576660661; Sun, 03 Jul 2016 13:11:00 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Sun, 3 Jul 2016 13:11:00 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <57761101.3030101@freebsd.org> <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org> From: Warner Losh Date: Sun, 3 Jul 2016 14:11:00 -0600 X-Google-Sender-Auth: 6dKLTeRARZHGUyjQWLKVe2aJG7k Message-ID: Subject: Re: Review request: sparse CPU ID maps To: Adrian Chadd Cc: Nathan Whitehorn , "freebsd-hackers@freebsd.org" , outro pessoa Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 20:11:01 -0000 On Sun, Jul 3, 2016 at 1:37 PM, Adrian Chadd wrote: > On 2 July 2016 at 17:08, Nathan Whitehorn 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