Date: Tue, 26 Feb 2019 08:54:06 -0800 From: Enji Cooper <yaneurabeya@gmail.com> To: rgrimes@freebsd.org Cc: Shawn Webb <shawn.webb@hardenedbsd.org>, "K. Macy" <kmacy@freebsd.org>, svn-src-head@freebsd.org, Matt Macy <mmacy@freebsd.org>, svn-src-all@freebsd.org, Brooks Davis <brooks@freebsd.org>, src-committers <src-committers@freebsd.org> Subject: Re: svn commit: r344487 - in head/sys: conf gnu/gcov Message-ID: <0E5630EC-A56B-4B02-9057-AA1C77C7849B@gmail.com> In-Reply-To: <201902261627.x1QGRefq046574@pdx.rh.CN85.dnsmgr.net> References: <201902261627.x1QGRefq046574@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Feb 26, 2019, at 8:27 AM, Rodney W. Grimes = <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: =E2=80=A6 > Didnt we just remove an inbase, compiling BSD licensed chunk of > code called DRM and move it to ports. So if that was possible > this should be very rapidly applied here and this issue goes away. >=20 > I am still shaking my head over this one. Yes, there is some > expediance to this. Also could it not live on a project > branch? Like.. um.. the ZoL project branch? Kernel gcov provides a lot of value beyond ZoL. Knowing which branches = are being hit by analysis, then producing tests (or pruning dead = branches if need be), can greatly improve the quality of kernel code, = instead of making a discovery like, "I just tested a thing by running a = common workload, and it hit these branches by side-effect, but I omitted = these sets of branches, which resulted in panics post-release". Isilon used its own homegrown variant of this for many moons (and it was = a mess). This solution is great for developers/testers, minus the = concerns I (and others) have over licensing. Thanks, -Enji=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0E5630EC-A56B-4B02-9057-AA1C77C7849B>