Recent searches
Search options
Christoph Hellwig, who recently vetoed dma-mapping #rust bindings, stepped down as maintainer for the dma-mapping[1] and configfs[2] subsystems of the #Linux #kernel.
[1] https://git.kernel.org/torvalds/c/f7d5db965f3e132887779c6b449452db2b807caa
[2] https://git.kernel.org/torvalds/c/815291c11acda54515f1af5ce6fe307490de9127
2/ For the record:
* Christoph Hellwig might have dropped two #Linux #kernel maintainer positions (and a reviewer entry for VMALLOC), but kept four others, among them for the NVMe driver and the NVMe target driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n16933
* From a look at the lore archives it currently looks like hch is as busy as usual when it comes to contributing to the #LinuxKernel https://lore.kernel.org/all/?q=f%3A%22Christoph+Hellwig%22+d%3A2025-02-24..
@kernellogger Hopefully he is not burnt out of the whole project.
That being said, regular changes of maintainers is not a bad thing. Fresh blood bring new ideas, and hopefully also a willingness to go towards a multi-maintainer and collaborative world like DRM.
One can dream, right?
burnt out: does not look like it so far – https://fosstodon.org/@kernellogger/114071173610445437
dream: Yes. 
But FWIW, that is hardly a kernel specific problem when you for a brief moment consider subsystem like kinda separate projects (working under one umbrella in the kernel case). So maybe the whole FLOSS world need to change its habits. But of course for the kernel it would be good if Linus or the core maintainer at the yearly summit encouraged this way more.
@kernellogger Generation change started to happen?
@michalfita what makes you think so? this is just two MAINTAINER changes while hch is keeping four others - so I can't see anything to back up your claim, so sorry, it might be more harmful then helpful.
@kernellogger 
Linus personally suggested Linux need new generation of maintainers. How this may not happen w/o exiting ones stepping out?
@michalfita sure, but people stepping up and down all the time; I got the impression that you read something special into this even where there is nothing special here IMHO
@kernellogger You're free to own interpretation.
@kernellogger What happens once Rust hits NVMe area?
@oleksandr that is a good question that already immediately sprang to my mind, but I guess we are about to find out sooner or later, *if* there is any reason to use Rust in that area in the next few years…
@kernellogger @oleksandr there is https://rust-for-linux.com/nvme-driver, which was meant to show that rust can be used for implementing a generally useful device driver.
The driver is a great example because most people have the hardware to try it out and it interacts with a good set of kernel subsystems (pci, dma, block).
Requiring rust in the normal nvme driver was never an option but some had argued for merging it as an alternative driver.
@oleksandr @kernellogger Basic rust bindings are already in the block layer, which is one of the areas that Christoph contributes to quite a lot. It has not caused any issues. So let's not extrapolate on this topic any further.