Message-ID: <428e2df8-d5b7-a200-62c2-59497f3facea@xen0n.name>
Date:   Sat, 11 Mar 2023 16:10:44 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: [PATCH V2] LoongArch: Provide kernel fpu functions
Content-Language: en-US
To:     Christoph Hellwig <hch@infradead.org>,
        Huacai Chen <chenhuacai@loongson.cn>
Cc:     Arnd Bergmann <arnd@arndb.de>, Huacai Chen <chenhuacai@kernel.org>,
        loongarch@lists.linux.dev, linux-arch@vger.kernel.org,
        Xuefeng Li <lixuefeng@loongson.cn>,
        Guo Ren <guoren@kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn
References: <20230306031258.99230-1-chenhuacai@loongson.cn>
 <ZAoNPuyHQTqucYxn@infradead.org>
From:   WANG Xuerui <kernel@xen0n.name>
In-Reply-To: <ZAoNPuyHQTqucYxn@infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/10/23 00:45, Christoph Hellwig wrote:
> NAK, this needs to be an EXPORT_SYMBOL_GPL.
>
> Also no way we're going to merge this without an actual user.

Okay so I sat down for some Saturday afternoon archaeology, and this is 
indeed much hairier than I originally thought...

Basically the same conversation has happened back in 2019 [1][2][3], 
mainly over the breakage it caused for zfs (obviously non-GPL and 
out-of-tree, that apparently made people automatically ignore it), while 
the introducing commit d63e79b114c02 ("x86/fpu: Uninline 
kernel_fpu_begin()/end()") went in unnoticed at that time [4]. It's 
clear that my opinion fell under the same camp as Andy and Paolo 
("exporting as GPL" means "any usage of this symbol implies the module 
is in fact derived work"), but the others disagreed ("in practice we 
don't care if it has no in-kernel users, and even if it does it would 
have to be GPL anyway", IIUC).

For now I've only been tinkering with Navi GPUs on loongarch, and 
haven't got to try openzfs yet, but I surely don't want to start the 
debate all over again, and making the loongarch FPU helpers GPL-only 
works for me. However there's probably another question that Ruoyao 
pointed out: do we want to mark the neon/altivec/s390x helpers GPL-only 
right away? IMO this particular feature is not inherently arch-specific 
(the same would have to happen for every arch with optionally enabled 
extra state and instructions, not limited to FPU actually) so 
availability of such feature should preferably be made symmetric over 
arches.

Given the topic's sensitive nature I'd want to hear from more people 
before deciding to (not) write the patches; thanks in advance.

[1]: 
https://lore.kernel.org/all/761345df6285930339aced868ebf8ec459091383.1556807897.git.luto@kernel.org/
[2]: https://lore.kernel.org/all/20190522044204.24207-1-cyphar@cyphar.com/
[3]: 
https://lore.kernel.org/all/CAB9dFdsZb-sZixeOzrt8F50h1pnUK2W2Cxx8+xjhgd0=6xs7iw@mail.gmail.com/T/#u
[4]: 
https://lore.kernel.org/all/1430848300-27877-51-git-send-email-mingo@kernel.org/

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/