Re: priority of paths to kernel modules?

On Fri, Aug 24, 2018 at 2:14 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.
>

We're still trying to figure out that issue. I'd like to do this, but
there's a lot of moving parts and objections that I need to plow through
before it's a done deal. Expect further incremental steps. We already do
not build in the kernel for x86 or powerpc, which gives us a lot more
flexibility. The revert was a first step, not a final stop.


> 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 graphics team doesn't have to support what's in the tree, at all. One
of the things that we absolutely will be doing is putting in big scary
notices saying that these drivers are deprecated, that you should be using
the ports and to not expect any support and these drivers are present only
as a transition.

Other ideas that I'm exploring, is the notion of a poison pill for the
in-tree drivers. So, we put all the IDs for the *NEW* cards into a driver
(maybe the intel/radeon one, maybe a new one: there's pros and cons to each
that need to be looked at). All this driver does is return a probe value
that's tiny so it usually isn't accepted. But when it is, it prints a
message saying "This card isn't supported by the in-tree driver. You must
install the port" and fails to attach, which would fail X11 startup. Not
completely ideal, but the X11 startup already fails with little clue and
this would help.

Warner is acting in good faith. He's just trying to balance many demands in
> a compressed time period.
>

Yesterday, hours before Johannes' email went out, I was communicating with
the Lua boot loader guy about ways we could change the path the boot loader
users for certain modules and other such things to mitigate this problem.

Warner


> On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg <johalun0_at_gmail.com>
> wrote:
>
> > Hi
> >
> > Since we now stuck with drm2 in base for a few more years I have an idea
> > would make things much smoother for many of us, hugely reduce the amount
> of
> > bug reports we get and I think would be beneficial in other ways too.
> >
> > Current I run with something like this in /boot/loader.conf
> >
> >
> >
> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays"
> >
> > So I expect modules to be loaded in that order, with /boot/<mykernel>
> LAST.
> >
> > However, if you look at this
> > sysctl kern.module_path
> > kern.module_path:
> >
> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays
> >
> > /boot/kernel is inserted first and probably modules in /boot/kernel have
> > the highest priority. This is also proven by everyone wanting to use
> > drm*kmods that get drm.ko from base loaded instead of the installed in
> > /boot/modules.
> >
> > Please correct me if I'm wrong but if my understanding is correct this
> is a
> > flaw and /boot/<mykernel> should be inserted last so that any overlays or
> > custom modules have higher priority than the default ones.
> >
> > I can imagine this is also useful when building custom modules and you
> > don't want to overwrite or delete the default one in /boot/kernel...
> >
> > Cheers
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org"
> >
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>