Re: priority of paths to kernel modules?

On Fri, Aug 24, 2018 at 5:20 PM Warner Losh <imp_at_bsdimp.com> wrote:

>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
> freebsd-rwg_at_pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg <johalun0_at_gmail.com>
>> wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy <mmacy_at_freebsd.org>
>> wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE
>> wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs
>> of RE
>> > > > and the graphics team + user base on post-2013 hardware - the
>> graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights
>> to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply
>> say we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>
>> Since we are in code freeze we could all go work on those things :-)
>>
>
> Yes. That's why I wanted all removals to wait until after the freeze so
> that I could get the deprecation policy hammered out better, including a
> common set of guidelines to know when to remove, when to disable, and how
> to ease things out of the tree in as a non-disruptive way as possible.
>
>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose
>> to have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>>
>
> 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).


> The people that do nothing, not even install a graphics port, we might be
> able to 'poison pill' the drivers such that we fail the load hard enough
> X11 doesn't start, but with a clear error message about next steps. This is
> a bonus of leaving them in the tree: we would just have a silent failure
> otherwise as X11 tries to load i915kms.ko only to have no driver attach.
>
> > (Putting on my loader ballcap)
>> >
>> > I would like to change this after 12 branches to append by default and
>> > allow one to add ${kernel_path} to their module_path to override that,
>> > since the status quo has been such for 18 years and some may want to
>> > go back to that. I've personally been bitten by it a couple too many
>> > times to be happy with the current situation.
>> >
>> > (Takes off loader ballcap)
>>
>> I actually like this solution, it appears to be a win for everyone
>> and would make the road smoother in the future for similiar types
>> of things should they happen.
>>
>
> Generally, things don't conflict. I like this notion for a number of
> reasons. It lets me have a 'driver disk' which can be placed first in the
> load for install and not have to worry about naming. It also gives us more
> flexibility for things in the future. The time to propose it, however, was
> May so we could shake things out, so it's too late for this release I'm
> thinking. But if we do this after the freeze, then we're in good shape for
> having it in 13, or knowing why it's a bad idea.
>
> Warner
>