Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4937438yba; Wed, 8 May 2019 05:30:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqxq0HZcMLcSRjrOo6RuT865/T984yocSbLV8ygBfHcb8NHqkYhIIOqk31Uc6Yoxf27bcvw7 X-Received: by 2002:a63:f54c:: with SMTP id e12mr5683992pgk.62.1557318604328; Wed, 08 May 2019 05:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557318604; cv=none; d=google.com; s=arc-20160816; b=cDPDDOj/PKDXRdFTmo56GQzTlGNEbeP18HtkXRbDvtKfPeF5GvjuPH+V1n0clKPdsF nVxr/R55aWTdzZiMpfqMHr/9Vb6Aj3VUtaijX8wRnM69lEUgax+TiAhPbFNh8patenUc T4mZho3eiwOHQRKnL0Dh698BC7kwO3t07vCqCKsS9dhCmscfSMQMV0mhCmA2DJiMw80k bWl6CQG19y1GTdMvIdxF/44s4xH7QW7Ame7ftR7Qwx2p18XZFDYVxqYy9HxlIFUfjqNf aDqpLy3r5WhM8gsGYluGJofBQPINpFy7U+Fw7oeFV42eu6xXNrHH6XrhBb9P8BeYpnRE Iy4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject:dkim-signature; bh=IrtOUQ0KzNSaFmEWTYr//AVD9YJKIqSsEkTVPy9gmdo=; b=Hwuk45wCPxDbecBA+6DultQ/hjilFQp3TfoOI9lZyZaSzNTjnNwhaCx7z14CVORUY+ zHQWMjc5/5czbvANN//KdjHWidyzKN+/VnLW/3ltpqz9h6CifP498qYlgWISdBW1BQ98 yhJYbJ1yMYvTEvQT+zUftcE/WJibcJjNnWXdorrVFdHQZ+BBZLow+K+kuOh8ceN3/SK8 6c610XIHDUtJohSsRSIpGrNjyHcvDGxnrXQQ6fSHijimgCHo5LV1WxctYL08PkDA+4cJ FvsKuKn4s5u1dHElNapUxB3RuXR+nHWDjT1wY/u6Zdbaue6jyZor6sI0M/cG2mi/nXIl /3nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@newmedia-net.de header.s=mikd header.b=TLavmPmW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=newmedia-net.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v7si22322455pgs.387.2019.05.08.05.29.48; Wed, 08 May 2019 05:30:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@newmedia-net.de header.s=mikd header.b=TLavmPmW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=newmedia-net.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728578AbfEHM2b (ORCPT + 99 others); Wed, 8 May 2019 08:28:31 -0400 Received: from webmail.newmedia-net.de ([185.84.6.166]:52836 "EHLO webmail.newmedia-net.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727750AbfEHM2b (ORCPT ); Wed, 8 May 2019 08:28:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newmedia-net.de; s=mikd; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=IrtOUQ0KzNSaFmEWTYr//AVD9YJKIqSsEkTVPy9gmdo=; b=TLavmPmWFIUv/BvB0sJ30rbFZE9SdzoGBQV3wiktmQgm6sw96ECC5TidOyjA4TT7LtrIZ8eyfwvucoMBQZ4H8j+yk1ERSQpdBjPGgFI7w3UjJGc7kliAQ4zmvELGYZURQPZtzWPPUNlVXdACmyYDL9v7Zuvvf1yD3Z47fw4R6Jg=; Subject: Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export To: David Laight , 'Jiri Kosina' , Sebastian Andrzej Siewior Cc: Andy Lutomirski , Greg KH , LKML , Rik van Riel , "H. Peter Anvin" , "Jason A. Donenfeld" , Ard Biesheuvel , Dave Hansen , Ingo Molnar , Nicolai Stange , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , "x86@kernel.org" , "stable@vger.kernel.org" References: <761345df6285930339aced868ebf8ec459091383.1556807897.git.luto@kernel.org> <20190502154043.gfv4iplcvzjz3mc6@linutronix.de> <957b01f742ed47d1ac9e0ea1277d155b@AcuMS.aculab.com> From: Sebastian Gottschall Message-ID: Date: Wed, 8 May 2019 14:28:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <957b01f742ed47d1ac9e0ea1277d155b@AcuMS.aculab.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Received: from [212.111.244.1] (helo=[172.29.0.186]) by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1hOLgY-00006q-2S; Wed, 08 May 2019 14:28:34 +0200 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 07.05.2019 um 12:31 schrieb David Laight: > ... >> So I don't really see a problem with Andy's patch. If we want to annoy >> external non-GPL modules as much as possible, sure, that's for a separate >> discussion though (and I am sure many people would agree to that). >> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would >> be a good start I guess :) > As a writer on an external non-GPL module I'd point out: > 1 - Even if we wanted to 'upstream' our code it is very specific > and wouldn't really be wanted/accepted. > Even if accepted it would always be excluded from builds. > 2 - It would take man-years to make it meet the kernel code guidelines > and to make it portable (from x86). > It also contains conditionals because it gets build for windows. > I don't like a lot of it. > 3 - Almost all the calls to kernel functions are through a 'wrapper' > file that is compiled on the target system. > About the only functions that are directly called are ones like memcpy(). > 4 - It wouldn't be that hard, and would still be GPLv2 if we built > two loadable modules, one GPL and one non-GPL and put all our > wrapper functions in the GPL one. > We'd still need a small wrapper for the non-GPL module, but while > Non-GPL modules are supported at all it wouldn't be much work. > 5 - The continual tweaks for new kernel versions keep us in a job! > > Some of the _GPL exports are a PITA: > - we can't reference count network namespaces (without creating a socket). > - we can't reference count 'pid' structures making sending signals tricky. > - I thing the PCIe error handling functions that we ought to be using > are GPL. > > At the moment we've not needed the fpu :-) > > David unfortunatly some does like ZFS which is opensource, but just licensed under the wrong copyleft license which cannot be changed that easy. but its a big loss for the community if such projects get blocked or limited by a singe linux developer. but thats just my own oppinion (even if not intentionally targeted here of course). not every project on his planet is a nvidia driver blob. whats most important for me is not if its GPL or not. most important is that its opensource and copyleft. so the question is if it isnt possible to create a EXPORT_SYMBOL variant which includes acceptable license models, but still restricts unacceptable licenses Sebastian