svn commit: r344487 - in head/sys: conf gnu/gcov

[Rodney W. Grimes]

> 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 don't execute the ctors until coverage is enabled because I have to
> > manually find the symbols. The linker doesn't actually generate a ctor
> > section for functions in text.startup in spite of what Juniper's
> > linker commit would lead one to believe - presumably they have a
> > private linker script in addition to a private gcov port.  Thus, it
> > really could just work fine as a module. Nonetheless, everything to be
> > profiled needs to be compiled with instrumentation, so separating it
> > out makes very little sense to me. Although, I suppose ctfconvert +
> > dtrace module is somewhat analogous.
> > 
> > > 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.  The standard GPL v2.0 boiler plate should be added
> > > to this file along side the tag.
> > 
> > I've copied the full copyright attribution that is in the
> > corresponding files on Linux. Is there some reason why FreeBSD
> > requires the files to be inflated with the full license text where the
> > original lacks it?
> 
> We're not asking for the full text, just the standard block:
> 
> // This program is free software; you can redistribute it and/or
> // modify it under the terms of the GNU General Public License
> // as published by the Free Software Foundation; either version 2
> // of the License, or (at your option) any later version.
> // 
> // This program is distributed in the hope that it will be useful,
> // but WITHOUT ANY WARRANTY; without even the implied warranty of
> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> // GNU General Public License for more details.
> // 
> // You should have received a copy of the GNU General Public License
> // along with this program; if not, write to the Free Software
> // Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> // 02110-1301, USA.
> 
> This is from: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC4
> 
> We're not currently using SPDX to include licenses, largely because OSI
> completely and utterly botched BSD licenses.  Fixing this is WAY down
> the list of things on core's plate.  Unless someone takes ownership
> here, I don't see this changing any time soon.

What is it that got botched, and what is it that needs to be done,
some may think I do not support SPDX, I do, in that originally
it was about tagging the files to mark what license applies, and
I agree we should tag the files.  I howerver can not support the
concept that you can replace a copyright and/or license text in a
file with just a SPDX tag. 

Some sight Linux as a big project using SPDX, but if you dig into
it you find out they did this to recover from there sloppyness of
actually not having anything in some 6000 files in the kernel,
they simply tagged them all GPL 2 and boom they claim problem
solved.

> > > 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 licensed GCOV"
> > >
> > > needs to be added.
> > 
> > Yup.
> > 
> > >
> > > This commit needed more through review.
> > 
> > How would this be achieved:? I had several people on the review and no
> > one had substantive feedback.
> 
> For GPL stuff, add #core to the reviewers list and feel free to drop us
> an email to make sure we see it promptly.

Thank you Brooks, maybe also add that as a note to the text of the
internal document, and could we get the text in the committers
guide I sighted elsewhere to agree with the text in this internal
policy?

> -- Brooks
-- 
Rod Grimes                                                 rgrimes at freebsd.org