From owner-freebsd-current@freebsd.org Fri Aug 24 15:27:10 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D77A108CCF5 for ; Fri, 24 Aug 2018 15:27:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A6C38AA5C; Fri, 24 Aug 2018 15:27:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id C796E277FD; Fri, 24 Aug 2018 15:27:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f44.google.com with SMTP id e23-v6so6957519lfc.13; Fri, 24 Aug 2018 08:27:09 -0700 (PDT) X-Gm-Message-State: APzg51CLnFbf9/3UDxOYt/kGK2y6Nl1Aoa2rAMW2cF6SSD4GeoWWs0bK kR+nD67r1Bg9ttF93SkDj2PAwF3/gx91icX1ttc= X-Google-Smtp-Source: ANB0VdY9k6Bazzrf+3MzkYryH5HnSlGLNrZAlgkaiBEwwJxIuVh0neSCRB/HJdv9bOZd0ZJc9o8a3nR0XOdi5KMuBXg= X-Received: by 2002:a19:5154:: with SMTP id f81-v6mr1735569lfb.55.1535124428349; Fri, 24 Aug 2018 08:27:08 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Kyle Evans Date: Fri, 24 Aug 2018 10:26:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: priority of paths to kernel modules? To: Warner Losh Cc: "Rodney W. Grimes" , Kyle Evans , johalun0@gmail.com, Matthew Macy , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 15:27:10 -0000 On Fri, Aug 24, 2018 at 10:20 AM Warner Losh wrote: > > > > On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes wrote: >> >> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg = wrote: >> > > >> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy 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