I must be misunderstanding, but isn’t that symbol access limitation entirely useless? If someone has the technical knowhow to develop a kernel patch set, they certainly have the capability to do so on a kernel they’ve recompiled without this limitation.
Netgpu and the hazards of proprietary kernel modules
11–20 of 104 posts
Re: Netgpu and the hazards of proprietary kernel modules
#12Earlier quoted context omitted.
> The sad part is that, by all appearances, the goal of this work was not to add functionality for NVIDIA GPUs in particular. Lemon does not seem to be an NVIDIA employee; the patches included a Facebook email address.
Its interesting the person posting the objection uses an @nvidia.com address.
With the history between nvidia and Linux, it wouldn’t surprise me if they had people employed to keep nvidia from treading on kernel dev’s toes.
Re: Netgpu and the hazards of proprietary kernel modules
#13I must be misunderstanding, but isn’t that symbol access limitation entirely useless? If someone has the technical knowhow to develop a kernel patch set, they certainly have the capability to do so on a kernel they’ve recompiled without this limitation.
The purpose of it does not seem to be to stop anyone from ever doing this ever, but rather to discourage patch submitters from wasting upstream maintainer time with patches that can't be reviewed because they use one of these shim layers.
Re: Netgpu and the hazards of proprietary kernel modules
#14I must be misunderstanding, but isn’t that symbol access limitation entirely useless? If someone has the technical knowhow to develop a kernel patch set, they certainly have the capability to do so on a kernel they’ve recompiled without this limitation.
Sure, anyone can do that and it is entirely fair to use the software that way privately. The barrier is that they can’t distribute the resulting modules because no one else will have a kernel that has been modified this way.
Re: Netgpu and the hazards of proprietary kernel modules
#15NVIDIA is even undermining kernel development that they had no hand in, is this a first?
Re: Netgpu and the hazards of proprietary kernel modules
#16I must be misunderstanding, but isn’t that symbol access limitation entirely useless? If someone has the technical knowhow to develop a kernel patch set, they certainly have the capability to do so on a kernel they’ve recompiled without this limitation.
Sure, anyone can do that and it is entirely fair to use the software that way privately. The barrier is that they can’t distribute the resulting modules because no one else will have a kernel that has been modified this way.
Right of course, yours and the sibling comment explained it perfectly. Cheers.
Re: Netgpu and the hazards of proprietary kernel modules
#17Earlier quoted context omitted.
> The sad part is that, by all appearances, the goal of this work was not to add functionality for NVIDIA GPUs in particular. Lemon does not seem to be an NVIDIA employee; the patches included a Facebook email address.
Its interesting the person posting the objection uses an @nvidia.com address.
Which person?
Re: Netgpu and the hazards of proprietary kernel modules
#18There was a module that used CUDA to accelerate operations in the Linux kernel a few years ago (but the author knew better than to try to mainline it). I think it was this one: https://github.com/wbsun/kgpu/
Re: Netgpu and the hazards of proprietary kernel modules
#19I feel like all this needless bureaucracy could've been avoided completely if Linux hadn't turned into a target for everyone to (try to) put code in. The GPL allows modification and redistribution, after all. With this patch applied, any module that imports symbols from a proprietary module is itself marked as being proprietary, denying it access to GPL-only symbols. That's starting to sound like DRM.
> That's starting to sound like DRM. It's close, but the key difference is it doesn't actually restrict the user, since you're both legally allowed and technically able to build and use a kernel without that code.
That's the fallacy Google and Netflix used to push DRM into your proprietary GoogleChrome and open source GoogleChromium/MozillaFirefox browsers.
whatever helps you sleep at night...
Re: Netgpu and the hazards of proprietary kernel modules
#20Earlier quoted context omitted.
> That's starting to sound like DRM. It's close, but the key difference is it doesn't actually restrict the user, since you're both legally allowed and technically able to build and use a kernel without that code.
That's the fallacy Google and Netflix used to push DRM into your proprietary GoogleChrome and open source GoogleChromium/MozillaFirefox browsers. whatever helps you sleep at night...
If you remove the DRM from your browser, then you can't watch some content anymore. That's not the case with this code. You can remove it with no loss of functionality.