On Fri, Aug 24, 2018 at 10:20 AM Warner Losh <i...@bsdimp.com> wrote:
>
>
>
> 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.
>
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
_______________________________________________
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"
