Re: [RFC] Deprecation and removal of the drm2 driver

On Thu, 31 May 2018 18:02:26 +0200, "Ronald Klop" <ronald-lists_at_klop.ws> wrote:

> On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney <jmaloney_at_ixsystems.com>  
> wrote:
> 
> > 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.
> 
> 
> I would support an idea that the FreeBSD project only delivers CURRENT  
> (and one periodic release with security fixes) and parties like PC-BSD  
> maintain stable branches and support for companies.
> 
> I read about this somewhere a while ago and the idea sticks. Backporting  
> to code 2+ years old is not the best use of human volunteer resources IMHO.
> 
> Regards,
> Ronald.
> 
> 
> 
> >
> > 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"
> >>
> > _______________________________________________
> > 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"
> _______________________________________________
> 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"


Is there a way to do that and ensure that it can be installed also on low power
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.