From owner-freebsd-current@freebsd.org Fri Aug 24 15:03:06 2018 Return-Path: <owner-freebsd-current@freebsd.org> 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 690A2108C462 for <freebsd-current@mailman.ysv.freebsd.org>; Fri, 24 Aug 2018 15:03:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 EFFCA89DA4 for <freebsd-current@freebsd.org>; Fri, 24 Aug 2018 15:03:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id q4-v6so7367491iob.8 for <freebsd-current@freebsd.org>; Fri, 24 Aug 2018 08:03:05 -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=ssRrL8xY+X2dUqXu1iBiJy19bhu8eeXrS84P90nl4SY=; b=mVigOTZ5hoIlN4ze3YaQOJybmp6mY4fjCilJpHppb0Q+St65KL7nnOizXXYkp38Qdx Fs4RmOI5Qwu2ZiQ72/WWw/gs9OHppu3mOWnWkp/wN22Go4wgVlWtdAkULOPQXjHuYlCA tboaIi6XPC6saILUe2/r3tpkxtuLzvJrp3MgADfEgS925U5RyTt+gZdBzrcZPtM0TNrG 0qDRQV2g2/hBr0UmrhzkDJes50pyIj2luCy66K4akPRAIkyG9YpKPxndtsCIqiPlV4Gh LWSbgfE7ND/Q48f1DN5d43kawTyGbGVeWoWShDpDwRAbqPdCr+wiL+yq0LrRoOEtKzlt K5eQ== 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=ssRrL8xY+X2dUqXu1iBiJy19bhu8eeXrS84P90nl4SY=; b=BMUtw30+l6RFLKgQnNgOHSu+tlVaGtIZxgghkRdaSmi/OF7+ikADlYIwaMwg4NO2Rn FQjDJUG+IacDPTJgiYQdhZYLQrZHFRTR2P078rcUMyoJrdA5Aci+Cj7jgEDuVXYB6wqK WXPc7KAS6hrBraxGHEixPktflmUl9nZWEeW0WhAm/DvtZLmy+ebRdMHFt9qy1eCNnztG Ftmfrx6aXQaBAG0qPJzgLXAL0iepHdzhr8DvRWLMU3XMvYZiVes4VDBW6zuHXmvIiK2e R/cWJljRZ/StyZBFHfpM5kWCqapcV01sfyD2htBjhoL0iRJHcS1kcc0SiPZaDn1i4Cui Frsw== X-Gm-Message-State: APzg51D1zNlf6ygko7uoUgQe/GTfQR7+SzgnIQ4Y5uj2wZXRpiR6jfC+ nbTQsyS57f6RWGiMXtLob97SYT4nwt1jOgcwykr5gH2PQO4= X-Google-Smtp-Source: ANB0VdadVC3rejqnKV17Yns7Gwiw1A34zqaavHmWZTYZWpaY8ulfxnYhOrJZOABIuoOyxiqREZxIm5Oh1DfZWsXJN1I= X-Received: by 2002:a6b:d004:: with SMTP id x4-v6mr1493668ioa.299.1535122985122; Fri, 24 Aug 2018 08:03:05 -0700 (PDT) MIME-Version: 1.0 References: <CAECmPwu5suk9xaf4zWFYgVW6kkuUiFb1DviVR6VmQttjJUd56g@mail.gmail.com> <CAPrugNqFT28HxsZ4q-HfbwATLeD0asDr_nE0ZbH0cHjYXQPh2Q@mail.gmail.com> In-Reply-To: <CAPrugNqFT28HxsZ4q-HfbwATLeD0asDr_nE0ZbH0cHjYXQPh2Q@mail.gmail.com> From: Warner Losh <imp@bsdimp.com> Date: Fri, 24 Aug 2018 09:02:53 -0600 Message-ID: <CANCZdfqKDYkakS5Jh3_jEeVKD9cZ1Tdurz-HkBy7AHvTKN+_gw@mail.gmail.com> Subject: Re: priority of paths to kernel modules? To: Matt Macy <mmacy@freebsd.org> Cc: Johannes Lundberg <johalun0@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> 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 <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/> List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 24 Aug 2018 15:03:06 -0000 On Fri, Aug 24, 2018 at 2:14 AM Matthew Macy <mmacy@freebsd.org> 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. > We're still trying to figure out that issue. I'd like to do this, but there's a lot of moving parts and objections that I need to plow through before it's a done deal. Expect further incremental steps. We already do not build in the kernel for x86 or powerpc, which gives us a lot more flexibility. The revert was a first step, not a final stop. > 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 graphics team doesn't have to support what's in the tree, at all. One of the things that we absolutely will be doing is putting in big scary notices saying that these drivers are deprecated, that you should be using the ports and to not expect any support and these drivers are present only as a transition. Other ideas that I'm exploring, is the notion of a poison pill for the in-tree drivers. So, we put all the IDs for the *NEW* cards into a driver (maybe the intel/radeon one, maybe a new one: there's pros and cons to each that need to be looked at). All this driver does is return a probe value that's tiny so it usually isn't accepted. But when it is, it prints a message saying "This card isn't supported by the in-tree driver. You must install the port" and fails to attach, which would fail X11 startup. Not completely ideal, but the X11 startup already fails with little clue and this would help. Warner is acting in good faith. He's just trying to balance many demands in > a compressed time period. > Yesterday, hours before Johannes' email went out, I was communicating with the Lua boot loader guy about ways we could change the path the boot loader users for certain modules and other such things to mitigate this problem. Warner > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg <johalun0@gmail.com> > wrote: > > > Hi > > > > Since we now stuck with drm2 in base for a few more years I have an idea > > would make things much smoother for many of us, hugely reduce the amount > of > > bug reports we get and I think would be beneficial in other ways too. > > > > Current I run with something like this in /boot/loader.conf > > > > > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > > > So I expect modules to be loaded in that order, with /boot/<mykernel> > LAST. > > > > However, if you look at this > > sysctl kern.module_path > > kern.module_path: > > > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > > > /boot/kernel is inserted first and probably modules in /boot/kernel have > > the highest priority. This is also proven by everyone wanting to use > > drm*kmods that get drm.ko from base loaded instead of the installed in > > /boot/modules. > > > > Please correct me if I'm wrong but if my understanding is correct this > is a > > flaw and /boot/<mykernel> should be inserted last so that any overlays or > > custom modules have higher priority than the default ones. > > > > I can imagine this is also useful when building custom modules and you > > don't want to overwrite or delete the default one in /boot/kernel... > > > > Cheers > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >