svn commit: r335916 - head/sys/conf

[John Baldwin]

On 7/5/18 11:39 AM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 11:21:28AM -0700, John Baldwin wrote:
>> On 7/5/18 8:54 AM, Konstantin Belousov wrote:
>>> On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
>>>> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
>>>>> On Tue, Jul 03, 2018 at 11:05:42PM +0000, Matt Macy wrote:
>>>>>> Author: mmacy
>>>>>> Date: Tue Jul  3 23:05:42 2018
>>>>>> New Revision: 335916
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/335916
>>>>>>
>>>>>> Log:
>>>>>>   Enable MODULE_TIED by default for modules compiled with the kernel
>>>>> But why ?
>>>>
>>>> I think we should enable KLD_TIED to inline critical_* etc. for modules
>>>> built as part of a kernel that are installed alongside the kernel in /boot/<kerneldir>.
>>>
>>>> I don't think we need to support modules built with kernel A loaded into kernel B.
>>>>
>>> This is the crusial point.  I do not object, but this this is a radical
>>> change from the previous mode of modules build.
>>>
>>> I do not want to put words in other person mouth, but I beliee that the
>>> original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
>>> specific modules were to be tied.
>>
>> Yes, this is a change though I find it the logical outcome of the original change
>> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
>> intended to use MODULE_TIED in a few places, but I think tagging all those
>> places will be cumbersome and tedious compared to just doing it in this way.  I
>> think this will also tie into something I proposed earlier in a commit reply and
>> that I also brought up at BSDCan which is that I think that kernel modules in
>> ports should install their sources and build glue to some location we choose
>> (e.g. /usr/local/sys/modules/<foo>) and that we should support a variable folks
>> can set in their kernel config file similar to MODULES_OVERRIDE that is a list
>> of local modules to recompile and install into /boot/kernel along with other
>> modules (and that these recompiled modules would be TIED).  The binary module
>> from the package would still be present in /boot/modules, but the tied module
>> in /boot/kernel would be preferred and used instead when it exists (our existing
>> module_path already does this last part).  This would replace the existing
>> PORTS_MODULES but in a way that is more graceful and works with packages, not
>> just ports IMO.
>>
> 
> I probably need to say more explicit why this change made me surprised,
> and the surprise is fueled even more by your proposal.  It basically
> means that we do not need stable KBI, and detecting KBI breakage in such
> setup is practically impossible.  Most consumers would be recompiled,
> except the modules used in very specific scenario:  inter-release updates
> with the modules used from the portmgr-provided packages while packages
> are still built against the older release.
> 
> Again, I do not object against the proposed new world order, I do not
> believe that KBI stability gives positive value comparing with the burden
> and restrictions it puts on the liveness of the stable branches.
> 
> But I do believe that the migration to such new attitude to the kernel
> interfaces would benefit from the discussion.

I am not quite saying to abolish KBI as I don't think we need to ban the
ability to build standalone modules.  I just think that modules built with
a kernel should be tied to that kernel.  In particular as there is a push to
move from GENERIC towards MINIMAL, where more things like drivers are pulled
from modules instead of the base kernel file, there is a need for modules
built with the kernel to be less pessimized.  It is actually that factor more
than others that makes me want to tie modules built with a kernel to the
kernel.

-- 
John Baldwin