The real function of an LGPL kernel module shim isn't to sanction touching the kernel with non-GPL code, it's to protect the proprietary code on the far side of the shim from being forcibly published in the event of a GPL enforcement lawsuit victory. There's some question as to whether they constitute a reasonable defense now-since nobody has challenged any project for using an LGPL shim for 20 years and running-but in purely logical terms, there isn't much question that the shims don't accomplish much. He goes on to discuss the legally flimsy nature of the kernel module "shim" that the ZFS on Linux project (along with other non-GPL and non-weak-permissive projects, such as Nvidia's proprietary graphics drivers) use. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so." "Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that's their decision. "Honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle," he writes.
#Debian openzfs license
The line being drawn here is a very bright and functional one: Torvalds is saying that if you want to run in kernel space, you need to keep up with kernel development.įrom there, Torvalds branches out into license concerns, another topic on which he's accurate and reasonable. By definition, if you're looking for a kernel symbol, you aren't a user-space application. He notes that the famous kernel mantra "we don't break users" is "literally about user-space applications"-and so it does not apply to the decision to stop exporting kernel symbols to non-GPL kernel modules. Torvalds' position in last Monday's forum post starts out reasonable and well-informed-after all, he's Linus Torvalds, discussing the Linux kernel. The breaking change only affected bleeding-edge kernels that few ZFS users were using in production, and in July 2019 new, in-module state management code was committed to the ZFS on Linux source tree. AdvertisementĪlthough the change-and the way Kroah-Hartmann defended it-initially spawned a lot of drama and uncertainty, the long-term impact on the Linux ZFS community was fairly minimal. Kroah-Hartman's defense of the decision to stop exporting the symbol to non-GPL kernel modules appeared to be driven largely by spite, as borne out by his own comment regarding the change: "my tolerance for ZFS is pretty non-existent." Normally, ZFS-on any platform, including the BSDs-uses SSE/AVX SIMD vector optimization to speed up certain operations. Without access to the _kernel_fpu_ symbol, ZFS developers were initially forced to disable the SIMD optimizations entirely, with fairly significant real-world performance degradation. This increases the likelihood of catastrophic error within the kernel itself, since improperly restored state could cause a later kernel operation to crash. Removing access to that symbol therefore requires module developers to reinvent their own state-preservation code individually. The technical impact of refusing to continue exporting the _kernel_fpu_ symbol is not to prevent modules from accessing the FPU directly-it only prevents them from using the kernel's own state-management facilities to preserve and restore state. State preservation, whether in-kernel or native to kernel modules, makes sure that the original state of the FPU is restored before control is released to other kernel code that may be dependent on the values they last saw in the FPU's registers. Without access to that symbol, external kernel modules that access the FPU directly-as ZFS does-must implement state preservation code of their own. The particular symbol being discussed here, _kernel_fpu_, tracks the state of the processor's Floating Point Unit. In January 2019, senior kernel developer Greg Kroah-Hartman fierily defended a Linux kernel commit which disabled exporting certain kernel symbols to non-GPL loadable kernel modules.įor those whose heads are spinning, kernel symbol exports expose internal information about the kernel state to loadable kernel modules. The original January 2019 controversy, explained Given the massive weight automatically given Torvalds' words due to his status as founding developer and chief maintainer of the Linux kernel, we feel it's a good idea to explain both the controversial kernel change itself, and Torvalds' comments about both the change in question and the ZFS filesystem. After answering the user's actual question, Torvalds went on to make inaccurate and damaging claims about the ZFS filesystem itself. Last Monday in the "Moderated Discussions" forum at, Linus Torvalds-founding developer and current supreme maintainer of the Linux kernel- answered a user's question about a year-old kernel maintenance controversy that heavily impacted the ZFS on Linux project.
0 kommentar(er)
