"DRM removal soon" is premature

[Johannes Lundberg]

On Fri, Feb 15, 2019 at 09:44 Oliver Pinter <oliver.pinter at hardenedbsd.org>
wrote:

>
>
> On Friday, February 15, 2019, Johannes Lundberg <johalun0 at gmail.com>
> wrote:
>
>>
>> On 2/14/19 11:30 PM, Steve Kargl wrote:
>> > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote:
>> >> Not to pile on unnecessarily here, but I think the fundamental issue
>> is that
>> >> there is nobody who wants to maintain the in-tree DRM, and removal is
>> likely a
>> >> better option to half-assed maintenance. I'd imagine there'd be a
>> different
>> >> discussion if several developers were clamoring to keep this driver
>> well
>> >> maintained in the tree.
>> >>
>> > Unhooking a driver from the build, so that it cannot expose
>> > a change that breaks said driver is certainly a way to
>> > ensure the driver is not maintained.
>> >
>> > Wasted a weekend trying to find and attempting to fix the
>> > damage caused by a change in src/sys to the drm-legacy-kmod
>> > port.  You know, the port that was promised as part of the
>> > drm2 removal.  I would have spent this weekend testing
>> > changes to cexp, cexpf, the soon-to-be-submitted cexpl,
>> > ccosh, ccoshf, and the soon-to-be-submitted ccoshl.  That's
>> > all on hold now as I'm not sure when I'll be able to carve
>> > out time for testing.
>>
>> This happens all time for me with virtualbox-kmod as well in current.
>> Changes to src breaks certain (kmod) ports and there's always a delay
>> until they are fixed. This is life in -CURRENT. I accept this and don't
>> go bitching to virtualbox-kmod maintainers about it. Your usage is an
>> edge case so naturally there will be a longer delay before breakage is
>> noticed, until we can get automated CI up and running (even so, there
>> will be a delay).
>>
>> With graphics, there's a software fallback (vesa/scfb), virtualbox has
>> no such option.
>
>
> bhyve, pure qumu?
>

Yes bhyve is awesome and I use it mostly. Don’t get me wrong, I’m not
complaining about breakage, mearly stating the fact that that’s life in
-current. VBox kmods are usually fixed quickly, I think the biggest delay
is the time it takes to build all the packages. Maybe a fast lane for
critical kmod ports that can be upgraded/rebuilt isolated from the rest
would be something?




>
>>
>> For stable usage, there are -RELEASE options.
>>
>>
>>
>> _______________________________________________
>> freebsd-arch at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>>
>