On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg <johal...@gmail.com>
> wrote:
> > >
> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy <mm...@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.
Warner
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
