Re: priority of paths to kernel modules?

On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg <johalun0_at_gmail.com>
wrote:

> There's some tricks we can do here.
>>
>> First, I talked to Kyle yesterday about augmenting the Lua loader to have
>> a X_loadflag option. Some background. We look at a lot of X_xxxx flags for
>> loading modules. X_load=yes being the most familiar. One way to avoid POLA
>> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
>> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
>> the built-in load command so it knew that -K means 'add the kernel to the
>> path last rather than first'. This would solve one of the POLA violations
>> in a very targeted way: people that put i915kms_load=YES in their
>> loader.conf wouldn't be surprised by this transition. It would be at the
>> cost of 2 entires in loader.conf, I believe, and it shuts down one vector
>> of hassle for our users. People do this, btw, to get more lines / columns
>> in the BIOS boot environment for their console, so it's not an unreasonable
>> path to attend to.
>>
>> We could also have a sysctl that we could set to override specific
>> modules locations. This would allow the graphics port to have a rc script
>> that sets this up so when X11 goes to automatically load the module, the
>> right one gets loaded. This would solve the issue for the people that 'do
>> nothing' except install the port. While it's a small bit of programming for
>> the kernel, it's a general mechanism that's laser-focused on exceptions to
>> the rule w/o wholesale changes. This would solve the other main vector and
>> motivator for the 'kill it with fire' calls that doesn't leave behind a
>> scorched earth.
>>
>
>
> Just a small note here. With the modesetting driver (which is replacing
> the deprecated xf86-video-intel and is built into Xorg), X will not load
> the drm driver for you. It has to be done by putting kld_list="i915kms" in
> your rc.conf (I don't think loading drm next modules from /boot/loader.conf
> works).
>

I have done this in the past, but I had to jump through a number of hoops
to do it. I'll have to buy a laptop and see if I can do it with modern gear
and modern software.

But if X isn't loading the module for you, that makes the problem much,
much easier.

Warner