From owner-freebsd-current@freebsd.org Thu May 31 17:41:53 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 38875F79200 for ; Thu, 31 May 2018 17:41:53 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C95C974AEF; Thu, 31 May 2018 17:41:52 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.127] (helo=rmmprod05.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fORa2-0002IT-16; Thu, 31 May 2018 19:41:42 +0200 Received: from mail by rmmprod05.runbox with local (Exim 4.86_2) (envelope-from ) id 1fORa1-0005uA-VC; Thu, 31 May 2018 19:41:41 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Thu, 31 May 2018 17:41:41 GMT From: "Jeffrey Bouquet" To: "Ronald Klop" CC: "Daniel Eischen" , "Joe Maloney" , "Konstantin Belousov" , "Johannes Lundberg" , "freebsd-current" Subject: Re: [RFC] Deprecation and removal of the drm2 driver Date: Thu, 31 May 2018 10:41:41 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: Message-Id: 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 17:41:53 -0000 On Thu, 31 May 2018 18:02:26 +0200, "Ronald Klop" wr= ote: > On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney = =20=20 > wrote: >=20 > > 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=3D169433 > > > > That was a ticket which I chimed in on about a firmware I needed to mak= e=20=20 > > 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= =20=20 > > 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=20= =20 > > cherry > > picked for numerous 10.x releases. >=20 >=20 > I would support an idea that the FreeBSD project only delivers CURRENT=20= =20 > (and one periodic release with security fixes) and parties like PC-BSD=20= =20 > maintain stable branches and support for companies. >=20 > I read about this somewhere a while ago and the idea sticks. Backporting= =20=20 > to code 2+ years old is not the best use of human volunteer resources IMH= O. >=20 > Regards, > Ronald. >=20 >=20 >=20 > > > > Technically since I was using PC-BSD, and was a committer for that=20=20 > > 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=20= =20 > > issue > > trying to use stock FreeBSD because it was a simple backport. If my=20= =20 > > 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 wante= d=20=20 > > 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 easi= er > > to providing installation options for end users, and automating the post > > install action chosen in TrueOS, GhostBSD, and future derivative projec= ts > > tailored for the desktop use case. For example for TrueOS we boot the > > installer in failsafe mode with either VESA, or SCFB depending on wheth= er > > 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 modu= le > > path for either driver can more or less remain the same. Eventually wi= th > > 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= =20=20 > >>> from > >>>> kernel to ports to make it easier for the majority of the users to= =20=20 > >>>> load > >>>> the > >>>> correct driver without conflicts. > >>>> > >>> > >>> You do understand that you increase your maintainence load by this=20= =20 > >>> move. > >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in=20= =20 > >>> 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=20=20 > >> "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=20=20 > > "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" Is there a way to do that and ensure that it can be installed also on low p= ower and/or non UEFI -- mbr devices such as a 700 mhz ancient CPU? with the less memory? Not important any longer here due to time constraints but would ensure maybe a ten percent greater user base from here on out than otherwise... ........................................... If my overview is correct anyway.=