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

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"