Re: priority of paths to kernel modules?

> 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.

Since we are in code freeze we could all go work on those things :-)

> > > 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.

> (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.


-- 
Rod Grimes                                                 rgrimes_at_freebsd.org