lkml.org 
[lkml]   [2019]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86/fpu: Don't export __kernel_fpu_{begin,end}()
[cc += Ingo]

On Fri, Jan 11, 2019 at 06:40:58AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > > My tolerance for ZFS is pretty non-existant. Sun explicitly did not
> > > want their code to work on Linux, so why would we do extra work to get
> > > their code to work properly?
> >
> > ZoL facilitates seamless r/w cross-mounting with macOS, something no
> > other filesystem allows, and that feature is critical for me to work
> > on Linux drivers for Mac hardware. Please don't make life harder than
> > necessary for developers like me. Your "extra work" argument seems
> > disingenuous to me, Sebastian's patch is causing extra work for
> > ZFS developers, not the kernel community. The maintenance burden
> > for the kernel community to retain the export is zero.
>
> Sorry, no, we do not keep symbols exported for no in-kernel users.

AFAICS the only other alternative would be to remove the _GPL from
the export of kernel_fpu_begin()/end(). Those functions were static
inlines until v4.2 when Ingo uninlined them with commit d63e79b114c0
(x86/fpu: Uninline kernel_fpu_begin()/end()).

Ingo, why did you choose _GPL back then, given that the functions
were not restricted to GPL before? Any objections to making them
available to non-GPL again?

As it stands, v5.0 removes the ability from non-GPL modules to use
the FPU or SIMD instructions and that kills ZFS on Linux. This isn't
hurting Oracle, they're not using OpenZFS, it's only hurting ZoL users.

Thanks,

Lukas

\
 
 \ /
  Last update: 2019-01-11 19:06    [W:0.026 / U:4.540 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site