Date: Fri, 15 Feb 2019 10:07:23 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: Oliver Pinter <oliver.pinter@hardenedbsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: "DRM removal soon" is premature Message-ID: <CAECmPwt9_-mBmyu95E32hv=B_4jrKTNG7Yh2Lv1sYqU_MFNVpw@mail.gmail.com> In-Reply-To: <CAPQ4ffuyQckbe1mh9O02Shr0TgNv%2B=eC5%2BNkPcitpwFugnq8ig@mail.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> <CAPQ4ffuyQckbe1mh9O02Shr0TgNv%2B=eC5%2BNkPcitpwFugnq8ig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 15, 2019 at 09:44 Oliver Pinter <oliver.pinter@hardenedbsd.org> wrote: > > > 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? > Yes bhyve is awesome and I use it mostly. Don=E2=80=99t get me wrong, I=E2= =80=99m not complaining about breakage, mearly stating the fact that that=E2=80=99s lif= e 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@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?CAECmPwt9_-mBmyu95E32hv=B_4jrKTNG7Yh2Lv1sYqU_MFNVpw>