On 12.04.23 00:14, Miguel Ojeda wrote:
But, yes, if Rust grows to be really successful within the kernel, then at some point some basic understanding of Rust will be needed by most kernel developers. I think that is fine, as long as there is enough time to adjust.
The tricky question is: how much time will be needed ? Personally, I'm too overloaded for diving deeper into Rust anytime soon. I've recently managed giving up my reluctance against golang and doing some fun project w/ it (freecity, a simcity2000 clone), just to get some real hands-on experience (besides some smaller patches for other projects i've done over the years). Rust and golang share some common problems (when coming from traditional C + friends): * entirely different toolchain concept (workflows are very different from what one's used from GCC + friends) * fast-moving target (one has to be careful to expect/use the right toolchain version) * rarely understood by traditional kernel devs * distro/build engine integration/support still pretty infant, especially in embedded world (very related to the toolchain update problem) IMHO, before we can practically use Rust at greater scale in the kernel, the problems above need to be resolved first. And that's something that the Rust community (not the kernel community) should take care of. And beware: demanding newer toolchains (thus newer distros), just for building the kernel, can easily cause *huge* trouble many organisations, especially in embedded field. Linux is used in lots of highly safety critical environments that need special verification processes and so cannot easily upgrade toolchains. If Linux some day suddenly requires another language like Rust, those would be immediately cut-off from newer releases. Ergo: the whole process of adding Rust to the Kernel needs to be done very, very carefully.
To be clear, it is still up to each subsystem to decide whether to take Rust code. What I meant by "if they can" is that, if they are willing to, then ideally the code would go through their tree too. The exception are core APIs, where I asked for flexibility from all sides, so that those subsystems willing to try Rust do not get completely > blocked.
For the reasons above, the subsystems shouldn't take those decisions lightly, even if they happen to be Rust experts - this could have a dramatic effect on downstreams. Maybe we should (for certain time) go a different path: move all new Rust stuff (except for bugfixes) to a separate downstream tree, that's rebased on mainline releases, but still let the patches fload through the corresponding subsystems. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
