From owner-freebsd-current@freebsd.org Fri Aug 24 16:45:02 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 6EE7A108E97A for ; Fri, 24 Aug 2018 16:45:02 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 D87FB8D785; Fri, 24 Aug 2018 16:45:01 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id q8-v6so2251346wmq.4; Fri, 24 Aug 2018 09:45:01 -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=/LV4my5RRargcD9f2SXZUx0k8nC6BybLAj3x+cVY4JM=; b=GPLxQCA3h5id+W3FrfbarR9LDNtgmLbcR60WwSx+GU1SOEbqIkScDfgn+IUHVreOS+ RkI6uW5WDvkfCTriY6TX6YTbbI6ISr1hCKbyvlY22xUR6AxuUP+IwhOTekogGpLKqBKK 1I81Ra3yhFTclqXZQP0FFvPRyYcBGQMQ/YxR1sDqXtt1eLjVte2E29nfHPMmLYZE4/pm yRTBxOKPq6p5SKDzFZHQTKO6cQrL5t9k95hD40s10eim2VjrSIwy2j88nab2Ms6lgx8R YXtnJ9uYIaO19vRisVgYQJGkqBMjqn4buIkvsFDEtn6/OUMZORXcs/2FDfxkykjfcIP+ R4rw== 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=/LV4my5RRargcD9f2SXZUx0k8nC6BybLAj3x+cVY4JM=; b=QR/2zRuyFNJthuPhLcqZ8mjnxyM5HK7i4ruPRtLK8tgb4vPuqieIGOF5v5mfdukWLp gLNAQ82El8sKhiOfNJvI1dOBYj5OpR6lo6JddnBi3U9YlNqXEJH/wxAFNj88jVxFLRFd a1hAgSbIBri7bvk5Zw79pYJpAm1IGe9MkWT1PjcYazgiFROS8kFlXcdQYgZ1s4TR9ErC FvObPGNtOEmyjO15D0J0+xY1DV6IgrGhr591vsS3yo73vYYDNOQrpia3DromzMUrTNS0 F+RLqU1egdf+NxdhovVfjrYBDlE4f5QE3vxpz+vBFvf5iwE/E/0pJ4WiNSSht1b/zloQ qj+w== X-Gm-Message-State: APzg51Cx3KmatPfzGZY6xJ6GDU/QTZ99M1C15bsXrTauDhSAE4VFniMR uUGcX4GpsnqnNgndka55pAoC1hM+EYfHsDmYLsE= X-Google-Smtp-Source: ANB0VdYRa5Bjbb5L1mBQaNHBEbBAlf9ujv51axRK0H6LCbReMlPNDi894eccBbvmWPNSODBle+gircT3SWpW54A5cZQ= X-Received: by 2002:a1c:f03:: with SMTP id 3-v6mr1890685wmp.129.1535129100654; Fri, 24 Aug 2018 09:45:00 -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 18:44:23 +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 16:45:02 -0000 On Fri, Aug 24, 2018 at 5:43 PM Warner Losh wrote: > > > 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. > Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon, X might still do it. Need to test to confirm. However, there's nothing stopping you from loading it in rc.conf before starting X (which is probably better anyway). > Warner >