From owner-freebsd-current@freebsd.org Fri Aug 24 15:27:45 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 8C676108CD23 for ; Fri, 24 Aug 2018 15:27:45 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 05C8A8AAC9; Fri, 24 Aug 2018 15:27:45 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id m199-v6so4546458wma.1; Fri, 24 Aug 2018 08:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sfh6O/V/hEaAA1A0yT4J4CuPJV/2hx6kvRuFFwdqY7g=; b=FfS2SDXIclMuXWMbGl0K38SsrnV8YEiDvVkSijsh7mgBkwmDves031Ho/IHJgtF5Cr W9Xm9IJTaleCvKx/gzsEk4540cXMhfqCcdCIpiqADdSXKHtUbVtfZVINltKrywuAhPnv HxfYWtjdbMv7t0cCPsyILFftw35zhFgLhi+lHRvtTB+rpi/mCFY6v25E6FKyMfWkzdwc ank3EBuHrHvmR+nuAuOebBWIH4VfEN+d+ucgOCTWywTWxkHemAJIRevgIy4SJAZuF3ru Sk4XBtzpBGEgMUEQu9+5YZf03M0dTzOTk7t6jQj931gPAo5MkpVCWSxfezKKo08MztlZ AMJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sfh6O/V/hEaAA1A0yT4J4CuPJV/2hx6kvRuFFwdqY7g=; b=p2saDa2V7HajjF4H47iIx2mH7Ge2yjBq+ejpxGBA/UTtwy7z8B2/dnrxHFR5bxnCC9 Yai6Hr+hEiXE/CZTP/k4j4JpdzO3GXaSW7EnxXNOa+eh8pOcIDgYYRiuCRL2tPtqfQeR GIYjpxY9SGK24BtmbBA9yMYvqjkmRALP8Og7RIK84XlLQYpJGwYOV3YFf4HhfFCAnC/z wZdBohjEgaKtFJVDfKflpk7BY8L7Cq0t3kgvtBCOLnhPgLG12Kvl/8411yZ9rtDjmfko V3QQjX7U4LgJZD67KGe0gPjPprlK93jWbXGBP/Obw6JMm8bUQgHQ5Ej+DEZo8klbOy9w nFjg== X-Gm-Message-State: APzg51DQFoVvBETTFKVWARP+3mFeL/MVyfk4gL5wJW88/LiqGhRC7L88 k1IGaooVEI9vPkzIKqHNUzSDZDaOFyB4CXpMppKHtQ== X-Google-Smtp-Source: ANB0VdZa3QauAgi/IvTWIL+dM3M3j723/XSc3pXmQoPb1SkmRYuRX4OnVrk6Q7LDqFbHWNi+7AW4CDHT10iNYt4GGRA= X-Received: by 2002:a1c:55c2:: with SMTP id j185-v6mr1745002wmb.104.1535124463867; Fri, 24 Aug 2018 08:27:43 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Johannes Lundberg Date: Fri, 24 Aug 2018 17:27:06 +0200 Message-ID: Subject: Re: priority of paths to kernel modules? To: Warner Losh Cc: freebsd-rwg@pdx.rh.cn85.dnsmgr.net, kevans@freebsd.org, Matthew Macy , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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:45 -0000 On Fri, Aug 24, 2018 at 5:20 PM Warner Losh 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 >> wrote: >> > > >> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy >> 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. > Just a small note here. With the modesetting driver (which is replacing the deprecated xf86-video-intel and is built into Xorg), X will not load the drm driver for you. It has to be done by putting kld_list="i915kms" in your rc.conf (I don't think loading drm next modules from /boot/loader.conf works). > 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 >