From owner-freebsd-arch@freebsd.org Tue May 3 18:43:00 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 D7FB5B2AF9D for ; Tue, 3 May 2016 18:43:00 +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 4DD4C1366; Tue, 3 May 2016 18:42:59 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from [192.168.100.100] ([87.139.233.65]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjJCt-1bWSvW3Igp-00dUCU; Tue, 03 May 2016 20:37:53 +0200 Subject: Re: Default KMODDIR To: 'freebsd-arch' References: <1702887.zov9WbhYWY@ralph.baldwin.cx> <5728E634.7010108@gmx.de> <2852715.sr6RVszBnq@ralph.baldwin.cx> From: olli hauer Message-ID: <5728F001.50402@gmx.de> Date: Tue, 3 May 2016 20:37:53 +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: <2852715.sr6RVszBnq@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:OXTlHP3+2T2NEEC3Suz/yoZEAr5oaROudtMYkU5f7K++32ucbvZ ZIuWkBfMW7XOahwtntk8yQ4EsodHpGFgeg/BZeAhdxMNjhsEznTg0032feCEAjk23Nmr/mg TxjzXi+jsAqi593wVxCP8f10b3yNqaJUDl4BZc3KQSJfwPHbJgoXAxt8urWEGKV6KpWcG43 iboNfNDc7s3nvfQGKvBig== X-UI-Out-Filterresults: notjunk:1;V01:K0:fYo9O+xUi9w=:BEovx6dZDJuD/bASWzCEBo 53sSLV8Qacq3Hdp18x6FRP+15UIRh9x/L2fSB7egf4H71UXY1ZvJLwFsN4xmJ/HbEZQ2oilP7 x9nCmc2PW5x04jjRzmZJIc2eB+xlI0VKGJqxKQBtsb+ldLhXW7h1jcFJl1InyiCdZPNIJhDnI 4/0QJD5KuHPcqk69fmzm19KYW3e0Fr1lLh/oik43rofxuOO7BfUVKnu5gD/DvFHIdUYYDR3E0 +zMrCva9EHZbbCTbYBcMuA3YNKHNeisp9wL5LqhyYP2ZF+R0yuGFEvyktXgAgUehnOMwdIkb8 mwKrn0gGdW/EJNBIRF4fESiSsOc8ylUpg5I/1cQ4O42M0Uv12v5ZWBss6NYX6YR8t6cbocHjK /UO1B+0joUZSjgWrXUkqyyTLME33MNHINClbwZMckHQ0IlGcCZkPP35cqsUSomXXLbukNWNgn RyUMtcgHBncpRqw1/qkW7w9uiGpyQhr/dAos7pD3yPQD4qU2pSDjANRyAB2XRbBlxIMiGLQVd 8d0gtHcT4IM42xmWjDYLwhoTbGIJE+R3aYrGgXTNjlU9l5iqPG+LRdxZAt0JUsjjxt5pKeJlb vDXUGh0wLIO08npapIXHUG6H2Lk72KzkN4hcv2stNcyFXsk/qoyWJ1dluEWu6zInoQP/N8lsf PLhEfgOiiGjU4Tl15o582pJJPnWDbbMsOWaCTcbH85m8D0I+F3SSbXpflo8JAqyKiF+ggSTNm 489qjBMoUHkThHHL/xjmuWtTJt7+5TQsoyOqFVMbEBn1MN+gnzKEmY1evwFH2MKdrht/knnOY wklPUSp 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 18:43:00 -0000 On 2016-05-03 20:16, John Baldwin wrote: > On Tuesday, May 03, 2016 07:56:04 PM olli hauer wrote: >> 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? > > No, kernel upgrades don't touch /boot/modules at all. Right now third > party drivers have to explicitly set KMODDIR. This would mean they no > longer have to do that as building a module "standalone" would now DTRT > out of the box when installing. > Thanks for clarification! -- olli