From owner-freebsd-arch@freebsd.org Tue May 3 17:56:14 2016 Return-Path: Delivered-To: freebsd-arch@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 B6980B2CDCF for ; Tue, 3 May 2016 17:56:14 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B53F179B; Tue, 3 May 2016 17:56:13 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from [192.168.100.100] ([87.139.233.65]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MYKGj-1bB2gu1wu1-00VBR8; Tue, 03 May 2016 19:56:05 +0200 Subject: Re: Default KMODDIR To: 'freebsd-arch' References: <1702887.zov9WbhYWY@ralph.baldwin.cx> From: olli hauer Message-ID: <5728E634.7010108@gmx.de> Date: Tue, 3 May 2016 19:56:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1702887.zov9WbhYWY@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:s/rclB6Yp9vDZKG7lLyx+ZSygf2wVtjPoBtl7WsBW2xLapfLeKD bafFHb82x+VnbSxdD+nsFqE4WTS5xNOxu3X09CYc/fion6rURDVOrOY9MUnB3v8GvY8mZN6 SSw7RpIIBVczCm+edOcrYKUonXSDhp5ZWc58lKK9PojOsBw9TYJfItTLcrR/HRAQMgrd4IL 9N2uguq9hNo95i2etUBnQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:LnB/xnUf+6c=:M3u+pj2r8HNmZ7GPA4UWz+ 1G39/2aDmfxt7jKAW44FLdTAEhYeQAZAfsVPTq72Oi0TdA4xzsJCDxPfB0csQf7zuomhcMGZF gnl4k1PK86wIWnbalXBYSVSb6Xb8J42avCQljckTPr6krj6bW8QyUWcAPhLDSyaN9VgTTfkN/ SJAHdUUoe76btEcc3HOCCGX370MplrfIkCbngFKRkm8zRTZ8q841/+vm5K/Qu3qGIbhfQT6sw opDJ8f/KvcvrRIcGBJdsIZSkTcEPeAZRP3sBMR9bbPwW746egkjl3ueTrO3g6vqMYVmRoAsfD 9ByMqDAJZD0Jfx7aPPo4bKKJnUJm3CdOeThrvHZYqC8hXjIusnoGpeA8hXzr6CWFJb5i5HRDu tlfcXMFnN/lLxU95qXkMqr0YkBbUtdP2thiWm+vmES4emA5ZsjIWhc1FTG4SIwwOalvbLHTSe 5lxKTrSls3pSwCQCqlyQh9PQTZKBZ9Ukg68Q1Yo4N3kO9kV60oXhC/HyvRQz4uqia3CZLUQ+a EIMahDz2NgXoHi3LTbCQgjLoEVM9ZRFpgYTXDa+t/F0xOPbUYGx12glFJEnwFGNaJGomfZj0h 2q5l13Rj0xER7FK5ugmA2tEswJM0XUywHASbJSBz3MoYfuGiYusC3wOXA17ioHqMC/owvIOxf PsiOYR4eNX/VfxP+NmiGfmQvRWw1VypEWutUES8ObO9pAxvGvZUOZzo7Ue5of8yk5Dg2g5QkK IFH9xGWTHyOyACvKqeyCA7tVEVD6Qo04FDo/5vCNMVsmrXgDUH7MIL2XRfALPW8PMvVJhQTkI Asu46gR X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:56:14 -0000 On 2016-05-03 19:36, John Baldwin wrote: > I'd like to change KMODDIR's default from /boot/kernel to /boot/modules. > Kernel builds already set KMODDIR explicitly in sys/conf/kern.pre.mk, so > the only modules affected would be modules built standalone outside of a > kernel build. There are two cases to consider I think: > > 1) Someone has installed a custom kernel and finds they need module > 'foo' that wasn't in their custom kernel. They might do: > > # cd /sys/modules/foo > # make all install > # kldload foo > > For myself, if I need this I find myself instead modifying my kernel > config to include the module in MODULES_OVERRIDE and then doing a > 'make buildkernel && make reinstallkernel' as this will work after my > next source upgrade. > > In this case, foo.ko would now end up in /boot/modules rather than > /boot/kernel. Note that if a user just does 'make load' instead of > 'make install' then nothing changes. > > 2) A module lives outside of the tree (or a vendor wishes to ship a > newer version as a standalone module). All of these modules (including > all of the one in ports) currently have to override KMODDIR explicitly > in the module Makefile. > > It is the 2) case I would like to make more seamless by changing the > default. This does change the behavior for 1) if someone is doing > 'make install' rather than 'make load' from a module build directory. ... Not totally sure about, but isn't /boot/modules used by third party drivers like original VMware and others? Will be there any impacts for this third party modules during kernel upgrades, like renaming modules to module.old? -- olli