Live data from Hacker News

Netgpu and the hazards of proprietary kernel modules

lwn.net

21–30 of 104 posts

Re: Netgpu and the hazards of proprietary kernel modules

#21

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.

One of the primary advantages for authors in contributing back code is to get their features/bug fixes incorporated so that they are maintained going forward and you don't have to maintain a separate code base yourself (i.e. saving work) If you maintain your own obscure fork, you lose many of the benefits of contributing code. This is particularly true for many for-profit companies: they want to forget about any driver work they contributed the second they stop making money selling it.

Re: Netgpu and the hazards of proprietary kernel modules

#23
It 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@lst.de/

Re: Netgpu and the hazards of proprietary kernel modules

#24
post #18

There 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/

> Treating the GPU as a computing co-processor.

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

#25

It 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

#26
post #25

It 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.

Can confirm: Haiku, FreedBSD, NetBSD, and DrangonflyBSD kernel communities have been quite friendly and helpful.

Re: Netgpu and the hazards of proprietary kernel modules

#27

It 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…

Yeah, this sort of tone on LKML has repeatedly driven me away from trying to upstream my patches. I don't need handholding and hugs, but if I'm going to get unconstructive toxicity like this then I'd rather just keep carrying my local patchset around.

Re: Netgpu and the hazards of proprietary kernel modules

#29
post #25

Earlier 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.

>DrangonflyBSD

I knew i forgot someone THANKS!

Re: Netgpu and the hazards of proprietary kernel modules

#30

It 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…

As a user and downstream developer, I'm glad that the Linux maintainers are committed to maintaining a sound architecture.

The idea that they need to be more polite about rejecting low quality work is puzzling to me.

Post reply on HN