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

From: Johannes Lundberg <>
Date: Thu, 31 May 2018 18:51:50 +0100
On Thu, May 31, 2018 at 4:34 PM Joe Maloney <> wrote:

> I personally wish that more drivers, and firmware were separated from
> base.
I'm not a committer 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:
> 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
>> _______________________________________________
>> mailing list
>> To unsubscribe, send any mail to "
>> "
Received on Thu May 31 2018 - 15:52:28 UTC

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