Date: Fri, 15 Feb 2019 10:44:03 +0100 From: Oliver Pinter <oliver.pinter@hardenedbsd.org> To: Johannes Lundberg <johalun0@gmail.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: "DRM removal soon" is premature Message-ID: <CAPQ4ffuyQckbe1mh9O02Shr0TgNv%2B=eC5%2BNkPcitpwFugnq8ig@mail.gmail.com> In-Reply-To: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> 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> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, February 15, 2019, Johannes Lundberg <johalun0@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? > > For stable usage, there are -RELEASE options. > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4ffuyQckbe1mh9O02Shr0TgNv%2B=eC5%2BNkPcitpwFugnq8ig>