> On May 3, 2019, at 11:07 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > >> On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote: >> Your observation that the API only exists on x86 and s390 has no bearing >> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL. >> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec. >> It's just that SIMD code is so arch-specific that nobody has bothered >> unifying the namings (or, nobody considers the different names a problem >> at all). > > This is actually proving my point: there wasn't any real agreement on > what interfaces should be immutable so that out-of-tree code can use > them and us guaranteeing they won't change. Instead, it was a random > thing that just happened. > I don’t think I or has said we should try to make these interfaces immutable. What I’m saying is that, since we’re exporting the symbol anyway and it’s not particularly Linuxy, that we shouldn’t say that only *GPL* out-of-tree modules may use it. It seems like anyone who wants to put the effort into tracking which kernel has which symbols and is willing to accept the utter instability of the interface may use it. So if we ever unexport the symbol entirely, I won’t object. I object to what I consider to be the inappropriate claim that it’s a *GPL* export. (I actually hope we unexport it once simd_get() and friends land — they’re a much better API, and we should migrate over to it.)
