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 <deischen_at_freebsd.org> 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_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Thu May 31 2018 - 13:34:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC