Re:Killing a process and all of its descendants
by pas on Friday August 09, 2019 @06:40PM
(#20658785)
Huh. I never said it'll be magically accepted.
But you also can't say that it's somehow impossible to get anything other than what Linus et al. think is the very epitome of perfect.
Upstreaming stuff is an effort. Contributing to such a complex and fragile pile of code/crap/C must be done through the kernel devs.
But if you want to add a new FS, I/O scheduler, bytecode VM, or whatever, it's possible. Look at Ceph, btrfs, bcachefs, all the SSD/NAND oriented FS-es, look at eBPF, and the XDP [eXpress Data Path] IO Visor network thingie, or WireGuard [which is still not merged as far as I know, because it tried to bring its own crypto library instead of using the already existing stuff]. All the stuff getting upstreamed from Android piece by piece.
A lot of kernel devs are happy about this or that, but they are pragmatists.
And Linus doesn't veto big ideas just because, but does not want to pull sub-par implementations. (See KDBUS for example.)
But you also can't say that it's somehow impossible to get anything other than what Linus et al. think is the very epitome of perfect.
Upstreaming stuff is an effort. Contributing to such a complex and fragile pile of code/crap/C must be done through the kernel devs.
But if you want to add a new FS, I/O scheduler, bytecode VM, or whatever, it's possible. Look at Ceph, btrfs, bcachefs, all the SSD/NAND oriented FS-es, look at eBPF, and the XDP [eXpress Data Path] IO Visor network thingie, or WireGuard [which is still not merged as far as I know, because it tried to bring its own crypto library instead of using the already existing stuff]. All the stuff getting upstreamed from Android piece by piece.
A lot of kernel devs are happy about this or that, but they are pragmatists.
And Linus doesn't veto big ideas just because, but does not want to pull sub-par implementations. (See KDBUS for example.)