Date: Fri, 24 Aug 2018 10:26:56 -0500 From: Kyle Evans <kevans@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, Kyle Evans <kevans@freebsd.org>, johalun0@gmail.com, Matthew Macy <mmacy@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: priority of paths to kernel modules? Message-ID: <CACNAnaEyb--WVVyRX2BcVidQQSdSoHygH-v7T0_K_1JdYMXU8g@mail.gmail.com> In-Reply-To: <CANCZdfoNdFHM6Z8KVNrUCFzASjRLsd=dkw_fZGpJjsYmFzySUg@mail.gmail.com> References: <CACNAnaGMsifVntGHQ8T4-w6jL%2B2dx5e1Ciw3-CQ9W2MwF38mfg@mail.gmail.com> <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> <CANCZdfoNdFHM6Z8KVNrUCFzASjRLsd=dkw_fZGpJjsYmFzySUg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 24, 2018 at 10:20 AM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <freebsd-rwg@pdx.rh.cn85=
.dnsmgr.net> wrote:
>>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg <johalun0@gmail.com>=
wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy <mmacy@freebsd.org> wr=
ote:
>> > >
>> > > > 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 t=
o
>> > > > communicate this adequately and still meet the timeline that RE wa=
nted.
>> > > >
>> > > > 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 grap=
hics
>> > > > 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 unde=
rstatement.
>
>>
>> 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 t=
hat I could get the deprecation policy hammered out better, including a com=
mon set of guidelines to know when to remove, when to disable, and how to e=
ase 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 d=
emands
>> > > > 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=3Dyes being the most familiar. One way to avoid PO=
LA would be to have in boot/defaults/loader.conf a i915kms_loadflag=3D-K so=
that by default, we'd run load -K i915kms instead of load i915kms. We'd au=
gment 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 violati=
ons in a very targeted way: people that put i915kms_load=3DYES in their loa=
der.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 has=
sle 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 t=
o attend to.
>
> We could also have a sysctl that we could set to override specific module=
s locations. This would allow the graphics port to have a rc script that se=
ts 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' e=
xcept install the port. While it's a small bit of programming for the kerne=
l, 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 ear=
th.
>
> 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 X=
11 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 ot=
herwise 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 reas=
ons. 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 flexi=
bility for things in the future. The time to propose it, however, was May s=
o 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 i=
t 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEyb--WVVyRX2BcVidQQSdSoHygH-v7T0_K_1JdYMXU8g>