Date: Fri, 15 Feb 2019 09:07:08 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: freebsd-arch@freebsd.org Subject: Re: "DRM removal soon" is premature Message-ID: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> In-Reply-To: <20190214233000.GA2752@troutmask.apl.washington.edu> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <CANCZdfqy%2Bs3QtEu%2BAhTm-HoJfByjeA9EeUGZ_3VrThvrcWvBow@mail.gmail.com> <20190214182419.GA67872@troutmask.apl.washington.edu> <CANCZdfrBTjV-rqU-VNRkFeQV2449ebgqi9qAAXYR6J_wygfxPg@mail.gmail.com> <20190214190244.GA68143@troutmask.apl.washington.edu> <CANCZdfqx%2BnLoV_bJU0cARxgz4ZBR-X_eZyFCVWzozuir5FqwnQ@mail.gmail.com> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 i= s 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 diff= erent >> discussion if several developers were clamoring to keep this driver we= ll >> 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=20 > 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=20 > 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. For stable usage, there are -RELEASE options.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3b0ba403-ff96-8c94-6d98-40165473d1f3>