TPM is the Trusted Platform Module, a security chip in computers that can be used to verify the integrity of the boot process. Windows 11 requires a TPM 2.0 chip, which many older computers do not have. Windows 11 non-TPM is a pirated version with this requirement hacked out.
You and i read different things.
Apparently we did.
I hated how he worded them, but his arguments at greppable and understandable are valid arguments that go beyond rust and if he can read it or not or refuses to.
I’m failing to see how Rust code is not greppable unless you don’t speak Rust.
Mixing languages in a part of a project brings complexity and is often a huge ass nono because it makes things unreadable and hard to manage on a large scale.
An argument which I would acknowledge, but if the decision to do this has been made by the group it still is weird to see it blocked by an individual.
He also argues that a c interface exists to connect 2 parts of a system. The person that changes the interface should not have to alter the users of that interface, […] So if he changes the interface, the rust team will need to fix it, specially since they are the minority.
Nobody asked Hellwig to do this, in fact Krummrich said several times they would maintain the interface consuming the C code themselves. They just want one common interface for all Rust drivers, instead of replicating the same code in each driver. Which Hellwig never gives a substantial reply to.
That also doesnt mean he can change it in whatever way without worry, it is an interface change, that needs discussions and approvals ahead of time ofc.
Again not how I’m reading that thread. As Krummrich put it:
Surely you can expect maintainers of the Rust abstraction to help with integrating API changes – this isn’t different compared to driver / component maintainers helping with integrating fundamental API changes for their affected driver / component, like you’ve mentioned videobuf2-dma stuff.
How do you figure?
The only two “technical” arguments I could see were firstly that code should
[remain] greppable and maintainable
which unless I’m missing something boils down to “I don’t speak Rust”, and secondly that
The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this
which unless I’m missing something boils down to “I don’t speak Rust”, because ain’t nobody trying to add any other languages to the Linux code base.
Surely this can’t be the “decent technical reasoning” you are referring to? I have to admit I don’t follow kernel development that closely, but I was under the impression that integrating Rust into the code base was a long discussed initiative having the “official” blessing of the higher ups among the maintainers by now, so it seems odd to see it opposed in such harsh terms by a subsystem maintainer here:
I absolutely support using Rust in new codebase, but I do not at all in Linux.
And of course there is an XKCD about this: Average Familiarity (2501)
Title text: