From owner-freebsd-current@freebsd.org Fri Aug 24 15:43:38 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 417CE108D40B for ; Fri, 24 Aug 2018 15:43:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 C38488B622 for ; Fri, 24 Aug 2018 15:43:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id q5-v6so4264668iop.3 for ; Fri, 24 Aug 2018 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u5wQ7ogtliM4Am2zWnn5wOFsyY7EL9cZ2Dda3eDu7GU=; b=y8eDcs6gfcM2oM5ebzUT1MPhgi2mh3r+2IhiOZeiADF21J4FisWOP+Vda9OrG++glF E38NdW2IiGLlqNWcI2gfe+VkmfJrEZrozEk/xFxQNDvmS+krNP1RY+BFz0D8b4qDplp9 UEXsMw7+X3jOXQVYTFUa9/gGs+rsL0Jclpoka7F4Oihwt4OCwAiYuePkSRxHrP5bijDI 5fLfPI9HcUlv3iEyRMFmmaVpMo0IzWR8UXVotWPNbsMDllDL6xVd1XyI+GucnarZQN0i KChOCXaureYku+0pcRj6rd6HDeJhYFKaxlY2Sd6zBVHsn/ZCVP2LjBmugtwuCj5U0zpo i9CQ== 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=u5wQ7ogtliM4Am2zWnn5wOFsyY7EL9cZ2Dda3eDu7GU=; b=Lt7Ub4ToNhkxCKlAzjwgj7yCriH/6kFZPnFG0JAaem8WArZcIaij7cYsyct3lTxqER LwcUg/75ErZQYmqf2LZ9O5weRp4SJhqEv8gZuvtj0c05LrX6rG7HUK+KI+bfbIN4tkDt /nb3vP+TD5WBCTvOaSUMQ/L1xa5nwNWEKQHCUInV8oyPLWsc7qb5wSAqjPMCaBv9FLWq OBGt337J0fXFlPXzcfrwkM80W+wPfGE7kKoLhcgwPwmgObsybye+x4nBkI0+wM+3xXwS Ql9nUD9TmUwrtQ+WlWh0j3fFfz7fR/t3NgB/KTBjhsksXxJaXaAlHFmdbfFKXtTnFl3w rELQ== X-Gm-Message-State: APzg51BfWrWf9uKbz7v3HWo67nhD1OYCPZOH5/Pa7nT0DtHKyh6LNFnN CtQ7hoyluKsgxPAlYk+YELgq4EB1ps/Hqkys5d5wqA== X-Google-Smtp-Source: ANB0VdbSmCw65DL1kkikrjCApF9TMpx9l9GMGTfL9JKEQwCughroMjxi4HZZumky0ogkaA/hxj+uvjL+GFxwTmUsGMY= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr1630966ioa.299.1535125417004; Fri, 24 Aug 2018 08:43:37 -0700 (PDT) MIME-Version: 1.0 References: <201808241411.w7OEBXg8095140@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Fri, 24 Aug 2018 09:43:25 -0600 Message-ID: Subject: Re: priority of paths to kernel modules? To: Johannes Lundberg Cc: "Rodney W. Grimes" , Kyle Evans , Matt 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:43:38 -0000 On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg wrote: > 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). > I have done this in the past, but I had to jump through a number of hoops to do it. I'll have to buy a laptop and see if I can do it with modern gear and modern software. But if X isn't loading the module for you, that makes the problem much, much easier. Warner