Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Aug 2018 18:44:23 +0200
From:      Johannes Lundberg <johalun0@gmail.com>
To:        Warner Losh <imp@bsdimp.com>
Cc:        freebsd-rwg@pdx.rh.cn85.dnsmgr.net, kevans@freebsd.org,  Matthew Macy <mmacy@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: priority of paths to kernel modules?
Message-ID:  <CAECmPwtHchQpq5ccCeCqZtB9S4qis_9-8_b_-qk%2B39vUWhA4HA@mail.gmail.com>
In-Reply-To: <CANCZdfryv44hD-oAB6cqJJAH2ZhX83ntswnO2K5ddhN5wP8mLQ@mail.gmail.com>
References:  <CACNAnaGMsifVntGHQ8T4-w6jL%2B2dx5e1Ciw3-CQ9W2MwF38mfg@mail.gmail.com> <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> <CANCZdfoNdFHM6Z8KVNrUCFzASjRLsd=dkw_fZGpJjsYmFzySUg@mail.gmail.com> <CAECmPwvouNd6J8Es4yC3Djr02ZeP=b88-aUFFA%2BHF-pYF3hb0w@mail.gmail.com> <CANCZdfryv44hD-oAB6cqJJAH2ZhX83ntswnO2K5ddhN5wP8mLQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 24, 2018 at 5:43 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg <johalun0@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.
>

Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon,
X might still do it. Need to test to confirm. However, there's nothing
stopping you from loading it in rc.conf before starting X (which is
probably better anyway).


> Warner
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAECmPwtHchQpq5ccCeCqZtB9S4qis_9-8_b_-qk%2B39vUWhA4HA>