Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp605867imu; Wed, 9 Jan 2019 03:21:48 -0800 (PST) X-Google-Smtp-Source: ALg8bN5XNOr2CqFb8II3SmBHYFncxlAC2UyflvG4RWv4qryqq1l60bYi7/R+a7bmmC2akhXA0kGR X-Received: by 2002:a17:902:6f09:: with SMTP id w9mr5740267plk.309.1547032908174; Wed, 09 Jan 2019 03:21:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547032908; cv=none; d=google.com; s=arc-20160816; b=X88euTdNHO0h2OYIwBpXjKrr6tuCEFdD8mpak6o9afJUCoH0aJtzao6N6XnmShL4XM FjTvFnyUi10qNMH9P59V3Xmj97cvE+RMUFgnpyO5+ssFTEawtBzyJMSKCWgCro7DUdww hoFzk0uSuWXNSj1pPi1crGDCQ36odOvOfvHq+XjqJ9AbyBxs9yjeFkDD/7zaczSyU384 am8E6iA/1AS3fXcAt/MKqe4332zrwlFz9sV49FGoc5Pag38KsssdvyLlqezvVidHFgVa es1/M9tc1o7ctACfNDeDuif4lBkZse38vfkSMtxmzkFiGFNU+PdwurWgt0szbPlbnOPb 0C9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=J7DEKHsq/hRYhGFe1PSYQW/loYN/3wX6r6uQSt0c8Fs=; b=kHh8Ct5ziFz4A26DrNOcdyoMGHyGlCf8e1v5LduGD1hePqNQDtUdyDSSBe364ijGjV GzNtL/Z5ucUsSDxh28ebSdPfFjvSu+2ZQ0zZ+vfP1iUfbhKMUBBvqOKBotwiAO5ROGVS VKTpwsijSYjdFzTKI7Ms+8l+GHpgbXw5olfBJMUHrYrBZ8BIebJK7c53gznhypd/6t/v tiGtWr9N6jJCTLYSZx5Xr2/ELKRH83W4VxEmIgg1EWFW+hd3YiUwvtUbeMxhx0BEMQ6/ HfrRyyK+i+qnt0CWDsgVoa/A29fvnuJEv4ncT8nkoyFsJzaea1+KeZWoyMPlyQg3qBKR 0fnQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q14si35909226pgf.47.2019.01.09.03.21.32; Wed, 09 Jan 2019 03:21:48 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730339AbfAILTz convert rfc822-to-8bit (ORCPT + 99 others); Wed, 9 Jan 2019 06:19:55 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:55410 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729933AbfAILTy (ORCPT ); Wed, 9 Jan 2019 06:19:54 -0500 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1ghBto-00066B-B1; Wed, 09 Jan 2019 12:19:52 +0100 Date: Wed, 9 Jan 2019 12:19:52 +0100 From: Sebastian Andrzej Siewior To: Marc Dionne , Greg Kroah-Hartman , Linus Torvalds Cc: Linux Kernel Mailing List , x86@kernel.org Subject: Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() Message-ID: <20190109111951.5zvnj7ls6jv56p2u@linutronix.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-01-07 18:08:26 [-0400], Marc Dionne wrote: > On Thu, Dec 27, 2018 at 11:20 AM Linux Kernel Mailing List > wrote: > > > > Commit: 12209993e98c5fa1855c467f22a24e3d5b8be205 > > x86/fpu: Don't export __kernel_fpu_{begin,end}() > > … > > With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can > > be made static and not exported anymore. > > > This commit removes an exported function pair that is currently used > by out of tree modules, while the replacement pair > (kernel_fpu_begin/end) is EXPORT_SYMBOL_GPL. So this is making > existing functionality GPL only, which will probably be an issue for > several out of tree modules that use the fpu. > > Could kernel_fpu_begin/end be made plain EXPORT_SYMBOL? It can be used by OOT modules as long as they are not under a proprietary license. The change here is not for me to decide, I added the x86 maintainers to make their decision. I can make a patch if they say so. On the other hand could we just drop EXPORT_SYMBOL_GPL? I doubt this helps in any way yet please correct me if I am wrong. The kernel is GPL and everything links to it should be GPL compatible. People that don't specify a GPL compatible license either use wrapper around their binary blob or use EXPORT_SYMBOL functions. The latter group complains each time a function is not available anymore and we end up changing it to EXPORT_SYMBOL. So what do we gain from that EXPORT_SYMBOL_GPL? > Marc Sebastian