From owner-svn-src-all@freebsd.org Tue Oct 30 17:31:47 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9EC210EF3F6 for ; Tue, 30 Oct 2018 17:31:46 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C3BA70F1A for ; Tue, 30 Oct 2018 17:31:46 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1540920699; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=QdVl1J1Hec8pmm4tyHs+3yIkSDFyG63aOOJUNbTstgECwnOcDZzeu1Tzood2Sqa3bPA4x+JqwkHiZ JwCYyDriX2lwaM8PFn75Rf6T2pYE9bizVdub/dUBo0hQogI+xHySwhtNllOmOMTrzOSRytsyVQn4Py 0V+axlrLEoDs15GGId59VD/8OCB/fvjg4Ja43BJuiM9De+CkOKB7XV02E20NWcQTbvSljIochu90km PNCpvj5THFvP+OA9ixPrtXtp85bMnf0hL47Hyn8xjA0GE1yTXb3COrPLMbCh50ieukU48fnI6cpBWq JfBKdSRKFIfIxWg3FEGNuLjqv5ZwKEw== 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:to:from:subject:message-id:dkim-signature:from; bh=uwhVL21vKrvUJAUZAdPiLqpMYnPB9VpJXZGz/KJnGyY=; b=CQkfawKlCV9ETltXXyMeu+rbde1gvmeS3J3LiLEPcWDqFJwvNIOgP4kKw5CChYC16dPBuN8Ot3//V 7J07Cdt6lXnWp6x3YmCdg4hhFJ55r6SmQFNLh2eTmhkFcuVZ9/R1PWGeUA9/waOyuP6uJTZunGMXmG eJMX9lGCs6qGjACc9pPbg2TYX4OGnJMEM2tUeL4sL49ct9+PhFYgb4Jg2/zdNjhGBuEGfytn1fgn1b zsWGvKop9F8XJ+hBb1LVuqexjYhH6mI4gfZp6z0nhMmkn9kWAS8Iou+wsvPVyRtM1Yiuuf1y2w+vfP doF84yyhLu8R2qlSVO902N8IeKd0njg== ARC-Authentication-Results: i=1; outbound2.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:to:from:subject:message-id:from; bh=uwhVL21vKrvUJAUZAdPiLqpMYnPB9VpJXZGz/KJnGyY=; b=pdMFuYLk9eV2g6NCFnkpEiZKSjZKZrCP8S8onNoa7l21NQbpWHfkYi5uCVWdmuYqEYo+D8echoyj6 ghMLhvZN1CSjExL1BrNpXVxNc2fyIot5mT/YYgSh4YyCEJ12tjBmYvMP5Ir8PBYTJ34ZhSPGYllV6d JnWgMF3tualaRYTLi9BYDzNY4bH3AGUBzxbhZNvisgVRHXUir5DTgojVjsPyAG5WTmN5KFX6rha5DV yG67KMaSCk9B6p3ttnubDIbkRshS1Y8RWnCaDlwwy8csUjCC5hsXjnepv69pzXIWS3MSiETCvEbHys 1nqzvlwU3f26aT5bvidiIg6NG+GZNng== X-MHO-RoutePath: aGlwcGll X-MHO-User: a751cee6-dc69-11e8-a630-335f030b21f2 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 outbound2.ore.mailhop.org (Halon) with ESMTPSA id a751cee6-dc69-11e8-a630-335f030b21f2; Tue, 30 Oct 2018 17:31:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w9UHVaCB065148; Tue, 30 Oct 2018 11:31:36 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1540920696.22340.158.camel@freebsd.org> Subject: Re: svn commit: r339901 - head/sys/conf From: Ian Lepore To: John Baldwin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Tue, 30 Oct 2018 11:31:36 -0600 In-Reply-To: <0ed999f2-75d8-aabf-0e95-7c130b6b4777@FreeBSD.org> References: <201810300023.w9U0NcOb048740@repo.freebsd.org> <0ed999f2-75d8-aabf-0e95-7c130b6b4777@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 17:31:47 -0000 On Tue, 2018-10-30 at 09:40 -0700, John Baldwin wrote: > On 10/29/18 5:23 PM, John Baldwin wrote: > > > > Author: jhb > > Date: Tue Oct 30 00:23:37 2018 > > New Revision: 339901 > > URL: https://svnweb.freebsd.org/changeset/base/339901 > > > > Log: > >   Permit local kernel modules to be built as part of a kernel build. > >    > >   Add support for "local" modules.  By default, these modules are > >   located in LOCALBASE/sys/modules (where LOCALBASE defaults to > >   /usr/local).  Individual modules can be built along with a kernel by > >   defining LOCAL_MODULES to the list of modules.  Each is assumed to be > >   a subdirectory containing a valid Makefile.  If LOCAL_MODULES is not > >   specified, all of the modules present in LOCALBASE/sys/modules are > >   built and installed along with the kernel. > >    > >   This means that a port that installs a kernel module can choose to > >   install its source along with a suitable Makefile to > >   /usr/local/sys/modules/.  Future kernel builds will then include > >   that kernel module using the kernel configuration's opt_*.h headers > >   and install it into /boot/kernel along with other kernel-specific > >   modules. > >    > >   This is not trying to solve the issue of folks running GENERIC release > >   kernels, but is instead aimed at folks who build their own kernels. > >   For those folks this ensures that kernel modules from ports will > >   always be using the right KBI, etc.  This includes folks running any > >   KBI-breaking kernel configs (such as PAE). > >    > >   There are still some kinks to be worked out with cross-building (we > >   probably shouldn't include local modules in cross-built kernels by > >   default), but this is a sufficient starting point. > The intention is that if, say, the drm-kmod ports install a valid module > Makefile to /usr/local/sys/modules/drm/Makefile, then subsequent kernel > builds will automatically pull in that module.  Also, since "local" > modules are built after in-tree modules, if a ports module has the same > filename (foo.ko), it will be installed over top of the in-tree one > in /boot/kernel effectively replacing it.  Note that as with subdirectories > in sys/modules, a Makefile could just be a bsd.subdir.mk that installs > multiple modules. > > I do think that as a further step we might consider having certain ports > stop installing binary kernel modules altogether and only ship source > (especially ports with strong KBI ties to the kernel such as virtualbox > or drm).  Probably these ports would then use a post-install step to > compile against whatever source tree is present on the host and install > the module to /boot/modules.  Anyone compiling custom kernels wouldn't > use that module though after the next kernel recompile as the next kernel > would include a kernel-specific version in /boot/kernel that would take > precedence over the version in /boot/modules.  However, that version in > /boot/modules would still be needed for folks running release kernels that > never compile a kernel.  Further thought is probably required for the > "stock kernel" case to make sure we are really happy with that approach. > > Cross-building kernels is also a further consideration.  The current > patch always opts-in to building local modules unless you explicitly > out out by setting LOCAL_MODULES to an empty string or LOCALBASE to > something that doesn't exist.  This means that if you have a port/package > installed that ships kernel module sources and do a 'make tinderbox', > we will try to build that module on all architectures that build modules. > This is probably not what we want.  I did want this feature to default > to enabled for native kernels so that installing a port will Just Work(tm) > without requiring kernel config changes to enable modules and I'd like > to keep that.  Some thoughts I'm considering for cross-builds are: > > 1) Change the buildkernel and installkernel targets in Makefile.inc1 >    to explicitly pass LOCALBASE=/nonexistent as a parameter to make >    if TARGET_ARCH != MACHINE_ARCH or TARGET != MACHINE.  A user could >    explicitly request local modules for a kernel build by setting >    LOCALBASE explicitly when invoking buildkernel/installkernel. > Or something like .if ${TARGET_ARCH} != ${MACHINE_ARCH} LOCALBASE?= /usr/local/${TARGET_ARCH} .endif Then it's analogous under /usr/local to the /usr/src/${TARGET_ARCH} hierarchy that's used for cross-building base. This is how Warner set up the ports crossbuild mechanisms years ago that we still use at $work. -- Ian