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

From: Oliver Pinter <oliver.pinter_at_hardenedbsd.org>
Date: Fri, 1 Jun 2018 00:34:57 +0200
On Thursday, May 31, 2018, Johannes Lundberg <johalun0_at_gmail.com> wrote:

> On Thu, May 31, 2018 at 4:34 PM Joe Maloney <jmaloney_at_ixsystems.com>
> wrote:
>
> > I personally wish that more drivers, and firmware were separated from
> > base.
> >
> >
> I'm not a committer


>
>
If you are not a committer,  how and why want to remove drm2 from the base
system?

>From other side, how you want to maintain VM and other KPI changes in
unmaintained and abandoned port? ;) Or how you can guarantee to everyone
who breaks KPI to follow these breaks in an external abandoned port?


>
> but as I understand there's not pre-commit integration
> tests.. If one had that, plus that it would test build kmod ports against
> the pre-commit state of head as well, then maybe this would work.
>
>
> > 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
> >> "
> >>
> >
> >
> _______________________________________________
> 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 - 20:34:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC