On Sat, 23 Feb 2019 at 16:14, Matt Macy wrote:
>
> Author: mmacy
> Date: Sat Feb 23 21:14:00 2019
> New Revision: 344487
> URL: https://svnweb.freebsd.org/changeset/base/344487
>
> Log:
> gcov support
I've added gcov to https://wiki.freebsd.org/GPLinBase.
Hi Alan,
On Tue, Mar 5, 2019 at 8:28 AM Alan Somers wrote:
> It's not a problem with the version; they're built from the same
> source. But is there a problem with the compiler? Can a GCC-built
> kernel work with Clang-built world?
Sure; I use this configuration all the time (at least,
It's not a problem with the version; they're built from the same
source. But is there a problem with the compiler? Can a GCC-built
kernel work with Clang-built world?
On Tue, Mar 5, 2019 at 12:54 AM Matthew Macy wrote:
>
> World? It looks like there's a version mismatch between the kernel and
World? It looks like there's a version mismatch between the kernel and modules.
-M
On Thu, Feb 28, 2019 at 7:11 PM Alan Somers wrote:
>
> On Thu, Feb 28, 2019 at 6:40 PM Matthew Macy wrote:
> >
> > to config add:
> > options LINDEBUGFS
> > options GCOV
> >
> > compile kernel with gcc
On Thu, Feb 28, 2019 at 6:40 PM Matthew Macy wrote:
>
> to config add:
> options LINDEBUGFS
> options GCOV
>
> compile kernel with gcc (otherwise it will be a no-op)
>
> sysctl debug.gcov.enable=1
>
> mount -t debugfs debugfs /sys/kernel/debug
>
> (or wherever) and the output artifacts will
> On Feb 28, 2019, at 5:39 PM, Matthew Macy wrote:
>
> to config add:
> options LINDEBUGFS
> options GCOV
>
> compile kernel with gcc (otherwise it will be a no-op)
>
> sysctl debug.gcov.enable=1
>
> mount -t debugfs debugfs /sys/kernel/debug
>
> (or wherever) and the output artifacts will
to config add:
options LINDEBUGFS
options GCOV
compile kernel with gcc (otherwise it will be a no-op)
sysctl debug.gcov.enable=1
mount -t debugfs debugfs /sys/kernel/debug
(or wherever) and the output artifacts will appear under gcov/ - you need to be root to see the artifacts
gcov can then
On Sat, Feb 23, 2019 at 2:14 PM Matt Macy wrote:
>
> Author: mmacy
> Date: Sat Feb 23 21:14:00 2019
> New Revision: 344487
> URL: https://svnweb.freebsd.org/changeset/base/344487
>
> Log:
> gcov support
>
> add gcov support and export results as files in debugfs
>
> Reviewed by: hps@
>
> On Tue, Feb 26, 2019 at 05:52:48PM +, Brooks Davis wrote:
> > On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
> > > > An additional issue is that the a warning tag was not added to
> > > > sys/conf/files. A warning along the lines of:
> > > >
> > > > warning "kernel
On Tue, Feb 26, 2019 at 05:52:48PM +, Brooks Davis wrote:
> On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
> > > An additional issue is that the a warning tag was not added to
> > > sys/conf/files. A warning along the lines of:
> > >
> > > warning "kernel contains GPLv2
> On Feb 25, 2019, at 7:18 PM, Rodney W. Grimes
> wrote:
>
>
> I think for a few reasons, I doubt you copied the whole distribution
> that this file came from, as I am sure that distribution included
> a LICENSE file. Second if you actually read the GPL v2 documentation
> and follow what it
On Tue, Feb 26, 2019 at 10:18:45AM -0700, Warner Losh wrote:
> On Tue, Feb 26, 2019 at 8:46 AM Shawn Webb
> wrote:
>
> > On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > > > The modest increase in activation energy for that task seems worth it
> > > > > for the short-term
On Tue, Feb 26, 2019 at 08:27:40AM -0800, Rodney W. Grimes wrote:
> > On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > > > The modest increase in activation energy for that task seems worth it
> > > > > for the short-term gains of reduced integration cost (this code will
> >
On 26/02/2019 13:15, Rodney W. Grimes wrote:
On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
We had a brief discussion of this commit within a subset of core. This
addition of GPLv2 code is fine as the code is easily removal to a module
(per kmoore@) should the day come that we're
> On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
> > > We had a brief discussion of this commit within a subset of core. This
> > > addition of GPLv2 code is fine as the code is easily removal to a module
> > > (per kmoore@) should the day come that we're read to evict all GPL code.
> >
> On 2/26/19 9:33 AM, Rodney W. Grimes wrote:
> >> On 2/25/19 5:11 PM, K. Macy wrote:
> This commit needed more through review.
> >>>
> >>> How would this be achieved:? I had several people on the review and no
> >>> one had substantive feedback.
> >>
> >> As a developer it is your
On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
> > We had a brief discussion of this commit within a subset of core. This
> > addition of GPLv2 code is fine as the code is easily removal to a module
> > (per kmoore@) should the day come that we're read to evict all GPL code.
>
> I
On 2/26/19 9:33 AM, Rodney W. Grimes wrote:
>> On 2/25/19 5:11 PM, K. Macy wrote:
This commit needed more through review.
>>>
>>> How would this be achieved:? I had several people on the review and no
>>> one had substantive feedback.
>>
>> As a developer it is your responsibility to be aware
> On 2/25/19 5:11 PM, K. Macy wrote:
> >> This commit needed more through review.
> >
> > How would this be achieved:? I had several people on the review and no
> > one had substantive feedback.
>
> As a developer it is your responsibility to be aware of the policies that
> we do document. One
On 2/25/19 5:11 PM, K. Macy wrote:
>> This commit needed more through review.
>
> How would this be achieved:? I had several people on the review and no
> one had substantive feedback.
As a developer it is your responsibility to be aware of the policies that
we do document. One of the things in
On Tue, Feb 26, 2019 at 09:20 Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > This has zero impact on the licensing disposition of the kernel as
> > distributed as it is only used for test kernels. Tests compiled with
> > coverage instrumentation run much slower than even debug, one
> This has zero impact on the licensing disposition of the kernel as
> distributed as it is only used for test kernels. Tests compiled with
> coverage instrumentation run much slower than even debug, one would never
> ship this.
Shit happens, mistakes get made, and sadly the consequences for
On Tue, Feb 26, 2019 at 8:46 AM Shawn Webb
wrote:
> On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > > The modest increase in activation energy for that task seems worth it
> > > > for the short-term gains of reduced integration cost (this code will
> > > > greatly improve
This has zero impact on the licensing disposition of the kernel as
distributed as it is only used for test kernels. Tests compiled with
coverage instrumentation run much slower than even debug, one would never
ship this.
You are very much in the minority being more concerned with ideological
> On Feb 26, 2019, at 8:27 AM, Rodney W. Grimes
> wrote:
…
> 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.
>
> I am still shaking my head
> On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > > The modest increase in activation energy for that task seems worth it
> > > > for the short-term gains of reduced integration cost (this code will
> > > > greatly improve our ZFS-on-Linux test coverage.)
> > > >
> > > >
On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > The modest increase in activation energy for that task seems worth it
> > > for the short-term gains of reduced integration cost (this code will
> > > greatly improve our ZFS-on-Linux test coverage.)
> > >
> > > Rod rightly
...
>
> We intend to update our license policy to require core sign off for
> new GPL code to ensure we're not adding new, tightly integrated
> dependencies, to document that we're doing so knowingly, and
> to make sure steps aren't missed. The current document is at:
>
> > The modest increase in activation energy for that task seems worth it
> > for the short-term gains of reduced integration cost (this code will
> > greatly improve our ZFS-on-Linux test coverage.)
> >
> > Rod rightly points out that we haven't accepted SPDX tags alone as
> > license statements.
> We had a brief discussion of this commit within a subset of core. This
> addition of GPLv2 code is fine as the code is easily removal to a module
> (per kmoore@) should the day come that we're read to evict all GPL code.
I don't execute the ctors until coverage is enabled because I have to
On February 25, 2019 9:58:09 AM PST, Brooks Davis wrote:
>On Sat, Feb 23, 2019 at 09:14:00PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Sat Feb 23 21:14:00 2019
>> New Revision: 344487
>> URL: https://svnweb.freebsd.org/changeset/base/344487
>>
>> Log:
>> gcov support
>>
>> add
On Sat, Feb 23, 2019 at 09:14:00PM +, Matt Macy wrote:
> Author: mmacy
> Date: Sat Feb 23 21:14:00 2019
> New Revision: 344487
> URL: https://svnweb.freebsd.org/changeset/base/344487
>
> Log:
> gcov support
>
> add gcov support and export results as files in debugfs
We had a brief
In message <201902232152.x1nlqjkg032...@pdx.rh.cn85.dnsmgr.net>,
"Rodney W. Gri
mes" writes:
> > > Author: mmacy
> > > Date: Sat Feb 23 21:14:00 2019
> > > New Revision: 344487
> > > URL: https://svnweb.freebsd.org/changeset/base/344487
> > >
> > > Log:
> > > gcov support
> > >
> > > add
> > Author: mmacy
> > Date: Sat Feb 23 21:14:00 2019
> > New Revision: 344487
> > URL: https://svnweb.freebsd.org/changeset/base/344487
> >
> > Log:
> > gcov support
> >
> > add gcov support and export results as files in debugfs
> >
> > Reviewed by: hps@
> > MFC after:
> Author: mmacy
> Date: Sat Feb 23 21:14:00 2019
> New Revision: 344487
> URL: https://svnweb.freebsd.org/changeset/base/344487
>
> Log:
> gcov support
>
> add gcov support and export results as files in debugfs
>
> Reviewed by:hps@
> MFC after: 1 week
> Sponsored by:
35 matches
Mail list logo
