From owner-freebsd-current@freebsd.org Thu May 31 15:34:20 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 7D24EEF8A52 for ; Thu, 31 May 2018 15:34:20 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E7F26CA5D for ; Thu, 31 May 2018 15:34:19 +0000 (UTC) (envelope-from jmaloney@ixsystems.com) Received: by mail-qt0-x244.google.com with SMTP id e8-v6so28373177qth.0 for ; Thu, 31 May 2018 08:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ixsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8Td8l3Hnz9FB2DYq/62JoX+qtR3GgK+WB75cqwVMNHE=; b=EpzT35bcOMbbRtcRklQr3KHmWUM8m2LjY2wEvYhzPJNd/1V00smvH0EqD4iaMoVQ4y Q/1nTsQcE94cr3Ra0gHs3KE+QNHrLT4XpVQZgT8xgOAB08Iy6XXqDajgXFuxPOgmHEzz mxzRzzA+jMY+p60iTktakLWb3/S84GZoTy/7YJtrfBYHCVMWDd7P68RGrV8xKU/d2qu9 8ZuByJaf+ZEfDFjLvxCkTyy4++VPNiXfkKI5/n8VS38Ht0f5yNpstM1WaHXx/ZgfpyhS 1EDMaeXDJeY3MoUq2NxBbHozHH/3y22Wzg8dntlNaLJJQIiDysTB90mvFStWBgqMr/OK VVzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8Td8l3Hnz9FB2DYq/62JoX+qtR3GgK+WB75cqwVMNHE=; b=KPq5xkrdSPvEQ2E6gUVAxLibpLYK8XV8Ql5xF7inddyuCCxlN9uaoJf41NqsegColP 3GQf/g67zxNYGhC0DZTIN1xIv7p+mpHwuYFDvHSB34iRRYD73lBWaBZ0z9ZKwt34U9xt DDeiUF+5nGEDMyQTWXTog2gegJa8MADnDsT6eYcEuwHh+sCP1OKtZZIrBX7u2F2bZXJO BnGqDX77XF0E4ZQqr4EMixy3oCFo/KcJ8GKKqSaGH1DfjZX0OhenNNWkiVnN7Eq3wwCG bMjRCsn61GwnVh24XStZdk4H2vqVWkml0P2Awq2+TQ/qvMiOyvzMMXcA69gEHwsH89VE y6xA== X-Gm-Message-State: APt69E1X92EqVj/0OON+na6ksxRSueaOfa/ZLHdjChn7cXLVd0ONNFfc oa1ss9MHcgrvDJ6FC7xsGFCouANVnnYcFiXxg4knpw== X-Google-Smtp-Source: ADUXVKJTEUGMInL6OFYhX8gkqfOCa1gMccMFZvQpIg14kA1poWKSUFqBXzHghkFYBM5wc83tHpTNSiMonWmH9I0hSyY= X-Received: by 2002:a0c:b2ca:: with SMTP id d10-v6mr2048002qvf.16.1527780859240; Thu, 31 May 2018 08:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:41c2:0:0:0:0:0 with HTTP; Thu, 31 May 2018 08:34:18 -0700 (PDT) In-Reply-To: References: <20180524160234.GD68014@FreeBSD.org> <201805241610.w4OGAAGY041280@pdx.rh.CN85.dnsmgr.net> <20180530235156.310870d0@thor.intern.walstatt.dynvpn.de> <20180531101643.GV3789@kib.kiev.ua> From: Joe Maloney Date: Thu, 31 May 2018 11:34:18 -0400 Message-ID: Subject: Re: [RFC] Deprecation and removal of the drm2 driver To: Daniel Eischen Cc: Konstantin Belousov , Johannes Lundberg , freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 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: Thu, 31 May 2018 15:34:20 -0000 I personally wish that more drivers, and firmware were separated from base. For example wireless firmware: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 That was a ticket which I chimed in on about a firmware I needed to make my wireless adapter work. I went through numerous efforts on IRC, and elsewhere to try to bring attention that ticket in order to attempt to get that firmware backported for several 10.x releases in a row without success. The firmware worked perfectly fine in PC-BSD where it was cherry picked for numerous 10.x releases. Technically since I was using PC-BSD, and was a committer for that project I had no real dire need to reach out to FreeBSD about the issue. I was simply trying to help anyone else who might be encountering the same issue trying to use stock FreeBSD because it was a simple backport. If my effort had turned out to be more fruitful I would have spent more time pursuing tickets, diffs, or whatever to get more things back-ported when I found them. I am not sure where the breakdown was which did not allow that to happen. Anyways I don't want to bikeshed, or anything but I just wanted to point out how I think having more drivers, and firmware in ports could be helpful to enhance compatibility for end users. Having a separate port for legacy drm could definitely make things easier to providing installation options for end users, and automating the post install action chosen in TrueOS, GhostBSD, and future derivative projects tailored for the desktop use case. For example for TrueOS we boot the installer in failsafe mode with either VESA, or SCFB depending on whether or not BIOS, or EFI is booted. Then we could simply make a checkbox for legacy intel, or skylake + to install the correct package then the module path for either driver can more or less remain the same. Eventually with something like devmatch maybe that can even be fully automatic. Joe Maloney On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen wrote: > On Thu, 31 May 2018, Konstantin Belousov wrote: > > On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: >> >> We're not replacing anything. We are moving the older drm1 and drm2 from >>> kernel to ports to make it easier for the majority of the users to load >>> the >>> correct driver without conflicts. >>> >> >> You do understand that you increase your maintainence load by this move. >> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable >> branches, so you will need to chase these updates. >> > > I agree. One argument previously made was that it's easier > to maintain in ports. One data point from me - I rarely > update my ports, I update my OS much more frequently. In > fact, some times my ports get so out of date I just > (take off and) nuke /usr/local (from orbit, it's the only > way to be sure). > > Also, are we trying to solve a problem by moving drm[2] to > ports that won't be a problem when base is pkg'ized? If > drm[2] is a package unto itself, then you don't have this > problem of ports conflicting with it, at least not so > much. You can either not install the base drm[2] package > or deinstall it to make way for a conflicting port. Once > drm[2] is pkg rm'd, it's not going to be reinstalled > again when you update the base OS. > > And don't we have the same problem with sendmail and a > few other base services? > > -- > DE > > _______________________________________________ > 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" >