[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65d890c8-9c37-070c-f5c6-db26ab8cfe54@xen0n.name>
Date: Mon, 6 Mar 2023 10:18:34 +0800
From: WANG Xuerui <kernel@...0n.name>
To: Huacai Chen <chenhuacai@...nel.org>, Xi Ruoyao <xry111@...111.site>
Cc: Huacai Chen <chenhuacai@...ngson.cn>,
Arnd Bergmann <arnd@...db.de>, loongarch@...ts.linux.dev,
linux-arch@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>,
Guo Ren <guoren@...nel.org>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH] LoongArch: Provide kernel fpu functions
On 2023/3/6 09:55, Huacai Chen wrote:
> On Sun, Mar 5, 2023 at 9:28 PM Xi Ruoyao <xry111@...111.site> wrote:
>>
>> On Sun, 2023-03-05 at 20:18 +0800, Huacai Chen wrote:
>>>> Might be good to provide some explanation in the commit message as to
>>>> why the pair of helpers should be GPL-only. Do they touch state buried
>>>> deep enough to make any downstream user a "derivative work"? Or are the
>>>> annotation inspired by arch/x86?
>>> Yes, just inspired by arch/x86, and I don't think these symbols should
>>> be used by non-GPL modules.
>>
>> Hmm, what if one of your partners wish to provide a proprietary GPU
>> driver using the FPU like this way? As a FLOSS developer I'd say "don't
>> do that, make your driver GPL". But for Loongson there may be a
>> commercial issue.
> So use EXPORT_SYMBOL can make life easier?
As I've detailed in my first reply, every arch other than x86 exposes
this functionality without the GPL-only restriction. Although IMO
non-GPL driver developers wouldn't grieve over this particular feature
simply because pretty much everyone would have to build on x86 and that
arch wouldn't have it exposed, I do think it will be more demanded on
loongarch, where HW performance is in general lower than x86/arm64
offerings at similar cost levels, so perhaps people would have to resort
to FP/SIMD tricks to reach performance on par with others.
Also, if the old world is taken into consideration (which we normally
have the luxury of not having to do so), consider Ruoyao's case where a
commercial partner of Loongson wants to do this with the vendor kernel,
but the symbols are exported GPL -- in this case I doubt the GPL marking
will remain, thus creating inconsistency between upstream and vendor
kernels, and community distros are going to complain loudly about the
need to patch things. It's probably best to avoid all of this upfront.
Note that this is all suggestion though, it's down to you and your team
to decide after all. And I've not done the archaeology about the other
arches' choice yet, which may or may not reveal more reasoning behind
their status quo.
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
Powered by blists - more mailing lists