I 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.
Netgpu and the hazards of proprietary kernel modules
21–30 of 104 posts
Re: Netgpu and the hazards of proprietary kernel modules
#22Re: Netgpu and the hazards of proprietary kernel modules
#23> "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!"
https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@lst.de/
Re: Netgpu and the hazards of proprietary kernel modules
#24There 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/
I'm starting to get mildly disappointed about this paradigm. GPUs have the hardware for very powerful dynamic parallelism, yet only CUDA supports that (since no GPU driver of note supports more than OpenCL 1.x). I'd much rather see the GPU-CPU pair used as a pair of nodes that are linked with a high-speed interconnect (PCIe), yet APIs apart from CUDA never moved much beyond the compute model of OpenCL 1.2.
Re: Netgpu and the hazards of proprietary kernel modules
#25It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…
Re: Netgpu and the hazards of proprietary kernel modules
#26It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…
All in all Linux (the kernel) has a really toxic environment. If you like a more friendly community and still want to work on a Kernel go to Net/Freebsd, Haiku or OmniosCE. With Linux (the kernel) you are not allowed to make mistakes or ask (stupid?) questions.
Re: Netgpu and the hazards of proprietary kernel modules
#27It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…
Re: Netgpu and the hazards of proprietary kernel modules
#28Re: Netgpu and the hazards of proprietary kernel modules
#29Earlier quoted context omitted.
All in all Linux (the kernel) has a really toxic environment. If you like a more friendly community and still want to work on a Kernel go to Net/Freebsd, Haiku or OmniosCE. With Linux (the kernel) you are not allowed to make mistakes or ask (stupid?) questions.
Can confirm: Haiku, FreedBSD, NetBSD, and DrangonflyBSD kernel communities have been quite friendly and helpful.
I knew i forgot someone THANKS!
Re: Netgpu and the hazards of proprietary kernel modules
#30It seems reasonable to reject the patch for technical and legal reasons, but it's pretty disappointing to see toxic comments from prominent kernel developers like: > "Seriously? If you only even considered this is something reasonable to do you should not be anywhere near Linux kernel development. Just go away!" https://lwn.net/ml/netdev/20200727073509.GB3917@lst.de/ https://lwn.net/ml/netdev/20200728064706.GA21377@l…
The idea that they need to be more polite about rejecting low quality work is puzzling to me.