From owner-freebsd-current@freebsd.org Wed Aug 14 16:22:22 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1DD97B1156 for ; Wed, 14 Aug 2019 16:22:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 467vxV01x0z4W46 for ; Wed, 14 Aug 2019 16:22:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id F1912B1152; Wed, 14 Aug 2019 16:22:21 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F1410B114E for ; Wed, 14 Aug 2019 16:22:21 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467vxT49xwz4W40 for ; Wed, 14 Aug 2019 16:22:21 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1565799740; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=A+uncAbq4VO1uHIK0+kuZcCWkRElii1nLIGezQdL7FVCvgs3q+RPL9RhhUm/Zxj+c/gKCU5+b+eNB YYQo3PINiqcQytHENof72X+fXypenODB4hFf0CLhnlVIpdtsK2GXjJ0kxZJOtl3Ga8vX3zOw5wa7Mj BjV7pKUVUdbCy9mcZobTYCwFdwxxRYGaNOnRxDeX3SWjJfRNAtYGEQ5kY1xLBzP1xjaEB7+Jmww5p2 P92rdWTTSrdyjnB8h76fBm45Jmwpbs8a8KPAKb6qzMbdDktjpqWhV/wL+sN1a23tR7HXlZ8S2kTjmr 4Uyy1hUwhcAgTB2zmKwkSxe0trMX2bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=SeipzOWiKp+QUpvf1Y+5wmnqjg681LJPBLqcfKi+OUQ=; b=gI7mDBdLKjKgCdX5Vh16B91KCNTT8atSCUt3U9MRPaqn4rKjGxqGQelpjf5me2dxn/TjOo7eOoWHf B1eZy1jAlLzD8USsjDDeW16w76QgXybwKMJEMNbAZ6VJY6GsCaLBJVE6D7TORRzlxSHCzD+Q6HU6PA apumJ8SGvCC7uTmXle7iKwCOd0EluVsBI/Y19aCq4HAwV16L9LQ3CYnXGstZA4/JkbMcz02YDkjAVf mC4xMCsl14plukzMJ1Wd3qp4vyaw6Nj5CfXCpSjiD5Gu22ZVeC+bgwvR1gL8Q5oj+CB7BCiE3PcuGG mCqrSx/ss58YiIGqIArb4hEH2/PuEgQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=SeipzOWiKp+QUpvf1Y+5wmnqjg681LJPBLqcfKi+OUQ=; b=jZs1RcbYSDRxEByZ8SYvKL3AEzg1y/Ch6cY6qiF/GvCtPHyqLdAtUUakXqIRU8t+ThuagRKa7nLAs rw+RtY1tWDoK7ZESnbqrUs1BcL2bbe3opZ3eyS+9LNKxcwp5B0KFppjRhnjF81f9SIcqP2Au8imLZU jxsm0+oFk7NrhxT5xkQgg2kOCeAnr2rXSP0HLUOeK95jiRXKKJIs57NsN2DpX7zfXPPuKkw36RW5V9 i0g2dmW+NylbchAIU/xtc7QOsPeCJtWLfn9LcgfQi32bCg+qf/ae0jbAf6yih216SwRCo7Wmpv8S7v efRM1W5d7i1KeWN28kDwfg+5sirAGPQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: aee05a76-beaf-11e9-b67b-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id aee05a76-beaf-11e9-b67b-cdd75d6ce7a8; Wed, 14 Aug 2019 16:22:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7EGMHsK055037; Wed, 14 Aug 2019 10:22:17 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <469b61c7c939b4e70f4304eaeb73eaae9b1d4c9a.camel@freebsd.org> Subject: Re: HEADSUP: drm-current-kmod now installs sources From: Ian Lepore To: John Baldwin , current@FreeBSD.org Cc: x11@FreeBSD.org Date: Wed, 14 Aug 2019 10:22:17 -0600 In-Reply-To: References: <67ca217f-b7de-8707-c4de-51e3f895d06f@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 467vxT49xwz4W40 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 16:22:22 -0000 On Wed, 2019-08-14 at 09:08 -0700, John Baldwin wrote: > On 8/13/19 3:17 PM, Ian Lepore wrote: > > On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: > > > For developers this means even if you are doing testing on a box > > > that doesn't use DRM, you can install the package so that kernel > > > builds will try to compile it and hopefully spot KPI/KBI changes > > > before they land in the tree so that the port/package can be > > > patched in tandem with committing changes to HEAD. Note that > > > even > > > builds of work trees in git checkouts, etc. will find the DRM > > > modules and try to build them if the package is installed. > > > > That last sentence sounds ominous. Are you saying that when I'm on > > my > > amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6 > > it's going to find /usr/local/sys/modules/drm-current-kmod and try > > to > > crossbuild it for armv6? > > Yes, meaning that you _can_ cross-build a DRM kernel module. This > also means > that if you are trying out a KPI change and have the package > installed, make > tinderbox will now catch a change that breaks the DRM drivers on only > a subset > of platforms (e.g. a powerpc or arm-only breakage that currently goes > unnoticed when a developer is only doing build testing from an amd64 > host). > > There are several ways you can disable this either globally or in > more > fine-grained ways: > > 1) You can set LOCALBASE to a different path either in a kernel > config > (via makeoptions) or when invoking buildkernel. > > For example, I mount my rpi's sdcard at /mnt on my amd64 laptop > and > then cross-build into it, so I could set LOCALBASE to > /mnt/usr/local when > building the rpi's kernel to honor any kmod packages installed on > the rpi. > > 2) You can set LOCAL_MODULES (makeoptions, command line) to a list of > modules > to build (empty disables building any of them). > > 3) You could set LOCAL_MODULES in /etc/src.conf to affect all kernel > builds. > (You probably don't want to set LOCALBASE there as it probably > affects > other things.) > > 4) You can build the port with the SOURCES option disabled if you > want to > never build modules for a specific port. > > > How about when I'm doing a build of 11-stable for testing, but > > what's > > in my /usr/local is sources for a 13-current driver? > > Given that the kmod's are supposed to be portable across branches, > the build really shouldn't be breaking. But the same ability is > still > there to as above to disable builds either in general or for > specific kernel configs or buildkernel invocations. > This all sounds vaguely wrong, backwards, to me. A developer who is using a given module on their build system might want that module to be rebuilt automatically, but only if the build parameters match those of the running build host system. If my build host is running freebsd 12 amd64 and I'm doing a build for freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64 driver module for a different OS arch and version just because that module happens to be installed on the system I use to do crossbuilds. My objections are theoretical... this automation just seems improperly designed to me. But it won't actually affect me in any way, because I don't build video driver modules from ports, and I don't run freebsd current on my build host machine. Probably the number of people doing crossbuilding is small enough that nobody else is going to object to this "the whole world is amd64" automation. -- Ian