Re: priority of paths to kernel modules?

On Fri, Aug 24, 2018 at 10:20 AM 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.
>
> 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.
>

I should probably have mentioned- the _loadflags solution is one I
feel comfortable with this late in the release cycle, but I would very
strongly prefer not to touch module_path in a stable branch (or
soon-to-be-stable branch) so that we have time to sort out the
ramifications for the odd-balls that depend on the current ordering
given its history. The ${kernel_path} override could allow something
like my described module_path change to happen in a stable branch, but
not for the upcoming release and any backport would most likely
involve changing the default to prepending ${kernel_path} so that
we're not surprising the aforementioned "odd-balls".

Thanks,

Kyle Evans