From owner-svn-src-head@freebsd.org Mon May 2 21:03:11 2016 Return-Path: Delivered-To: svn-src-head@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 C78D0B2A220 for ; Mon, 2 May 2016 21:03:11 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D834165C for ; Mon, 2 May 2016 21:03:11 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1462222989; bh=WaY1A3MPOeS/ruE02+bdDllYni5I2GQlGt9jPr5u1Ks=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=mCVZVBSX8wHyumhUt9hw7gdCmmZ0lMBEryVD/NXouV43wkrlYHfuGHk85u8rX7Zvnsrz/0z9aRxXsrCTmxamNj9JkfN34+hxCBrGgD9tPd6mNEYSNlnPYuvIOUsA3BLmbAgBDwsWZKYqJLJcsEZcNjwa+iIaXvPeZ2er69bY98nOz2LR2YIqakQPuFjEYol7uWgVXbJTsISUbw72Ud+mTtPL7i4g3g+tKmhQ+2t+/2RI2WrP7kA/8pxaEBhV81F3nIRGyTwcG2ONHocph7Y/fSY8mazxm+sXREmzSYDXrVG7h1DazaYrwKRmmPbSfySNqebFHaZvtRWvSviIkMRR/A== Received: from [98.139.170.180] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 02 May 2016 21:03:09 -0000 Received: from [68.142.230.65] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 02 May 2016 21:03:08 -0000 Received: from [127.0.0.1] by smtp222.mail.bf1.yahoo.com with NNFMP; 02 May 2016 21:03:08 -0000 X-Yahoo-Newman-Id: 956903.29917.bm@smtp222.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ONTnvkIVM1ngbQaYOBriU8CD60FYk8BfBVtFUl8ICDAz7.X PCstj1LYIvR8X95Phky.gxfkccubvh0AOt9ue_3.QyXPeLtco_8g6eDXV8Ux JYxWQVD.2bkva39WGBvqEbCnUoN5MTtVDcyu0.LB8Xy6S7eoucLwcvylRN2X imHIphGoyPjkg3WxqyIjcMhZV5zNC_VSaQCPMKNEi_lWFkj4tVnSmudqe7H0 L26dMzguAQ5qvPbMhOYD.elp_rHSl_K..BgsX0sHrUCyMSxR6IpspeEqfkY7 .SbkeNVxQCG6IStLx1Pnfm9KzRohktXraJrxguwyVK_giJSxPAX0obJKVzpQ ElGGe2tMCVGwmw0iVpgvOM_h9vL71HrCeABbMH5obVLX4GcyPQpaCS80wzxf 2n_RJPTyAE0zvSgnXsgWztAuznZuN.wdMnXLl8zdJn2Y5M2wtdk7JNT8ms2_ hz3bDuCPajIdYA2yY4eZTvYTtCbSCe3OJmffbshgMPVbff0RsK4TUnGQDzSn EZjlsYeEgcXvJ3ZWkCuLHzRPLBL_9ay25 X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: svn commit: r298933 - in head: share/man/man9 sys/amd64/include sys/dev/acpica sys/dev/drm2 sys/dev/drm2/i915 sys/kern sys/sys sys/x86/acpica sys/x86/x86 To: John Baldwin , "Ngie Cooper (yaneurabeya)" References: <201605021800.u42I0cjK084243@repo.freebsd.org> <4F040E00-AB92-4D32-99F5-9BCB02578DC0@gmail.com> <2097917.RNSsKXUJ7U@ralph.baldwin.cx> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Pedro Giffuni Message-ID: Date: Mon, 2 May 2016 16:03:13 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <2097917.RNSsKXUJ7U@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 21:03:11 -0000 On 05/02/16 15:52, John Baldwin wrote: > On Monday, May 02, 2016 11:45:41 AM Ngie Cooper wrote: >> >>> On May 2, 2016, at 11:00, John Baldwin wrote: >>> >>> Author: jhb >>> Date: Mon May 2 18:00:38 2016 >>> New Revision: 298933 >>> URL: https://svnweb.freebsd.org/changeset/base/298933 >>> >>> Log: >>> Add a new bus method to fetch device-specific CPU sets. >>> >>> bus_get_cpus() returns a specified set of CPUs for a device. It accepts >>> an enum for the second parameter that indicates the type of cpuset to >>> request. Currently two valus are supported: >>> >>> - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to >>> the device when DEVICE_NUMA is enabled) >>> - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core) >>> >>> For systems that do not support NUMA (or if it is not enabled in the kernel >>> config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus' >>> by default. The idea is that INTR_CPUS should always return a valid set. >>> >>> Device drivers which want to use per-CPU interrupts should start using >>> INTR_CPUS instead of simply assigning interrupts to all available CPUs. >>> In the future we may wish to add tunables to control the policy of >>> INTR_CPUS (e.g. should it be local-only or global, should it ignore >>> SMT threads or not). >>> >>> The x86 nexus driver exposes the internal set of interrupt CPUs from the >>> the x86 interrupt code via INTR_CPUS. >>> >>> The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable >>> LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and >>> the global INTR_CPUS set from the nexus driver with the per-domain set from >>> _PXM to generate a local INTR_CPUS set for child devices. >>> >>> Reviewed by: wblock (manpage) >>> Differential Revision: https://reviews.freebsd.org/D5519 >>> >>> Added: >>> head/share/man/man9/BUS_GET_CPUS.9 (contents, props changed) >>> Modified: >>> head/share/man/man9/Makefile >>> head/sys/amd64/include/intr_machdep.h >>> head/sys/dev/acpica/acpi.c >>> head/sys/dev/acpica/acpi_pci.c >>> head/sys/dev/acpica/acpi_pcib.c >>> head/sys/dev/acpica/acpi_pcib_acpi.c >>> head/sys/dev/acpica/acpi_pcib_pci.c >>> head/sys/dev/acpica/acpi_pcibvar.h >>> head/sys/dev/acpica/acpivar.h >>> head/sys/dev/drm2/drm_dp_iic_helper.c >>> head/sys/dev/drm2/i915/dvo.h >>> head/sys/kern/bus_if.m >>> head/sys/kern/subr_bus.c >>> head/sys/sys/bus.h >>> head/sys/x86/acpica/OsdEnvironment.c >>> head/sys/x86/x86/intr_machdep.c >>> head/sys/x86/x86/nexus.c >> >> This broke the build with gcc: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/1211/ > > I saw. What is odd though is that my tinderbox builds all passed. This might > be due to the recent howmany() changes since _bitset.h only needed > before but now needs (which is borderline to being pointless for > a _foo.h header). > TBH, I thought so too, but I avoided applying such changes to headers, and I haven't touched _bitset.h, Pedro.