Hi Hans! Thank you for chiming in! There's a few things in your email that I disagree with and that I'd like to address. > I think V4L2 should be written in primarily one language. It is, in C. This series is about adding *bindings* to write *drivers* in Rust *for those interested*. The v4l2 core remains untouched, and I don't think there are any plans to introduce Rust outside of drivers in the kernel at all, last I heard. > You assume that all code is running inside the kernel and needs to be perfect. No I do not assume that. In fact, Rust code is absolutely not guaranteed to be bug free and definitely not "perfect". On the other hand, I would take Rust over C any day. Thus I am contributing some of the infrastructure to make this possible for me and for others. IMHO I think you're approaching this from the wrong angle. It isn't that Linux *needs* Rust. It's more about providing a new and safer choice with modern ergonomics for developers, is all. > I would rather like more drive on that, than flowing down the Rust stream. These two things are not mutually exclusive :) > Rust is cool, Java is cool, VM's are cool. I don't see why Java and virtual machines are being brought into the discussion for this patchset here. And compilation times are a part of life, sadly. Also, can you substantiate your claim that Rust is slow? > Engineering energy would be much more focused, if hardware vendors could agree more about what binary formats to use for their device protocols, I understand, but my patchset is not to blame here. In fact, I have no say at all over these things. > than changing the coding language This simply is not what is happening here. Again this is about giving kernel developers another *option* of programming language, not about ditching C. > that now anyone can be let loose to program in the Linux kernel without risking any damage Who's "anyone"? Plus the review process stays in place, so hardly any changes to code quality here. > I'm glad if not everyone out there can do my job writing C-code for device drivers. We don't need more people to mess around there simply. Ok we differ strongly here. In particular, I am totally neutral to your first statement. The reality is that it isn't up to anyone to say who should or shouldn't become a kernel developer. The resources are out there for anyone to try, and if maintainers take in their patches, then that's the end of the story. -- Daniel
