Message-ID: <0da49a77-14d8-cb9d-e36d-985699746b6b@metux.net>
Date:   Wed, 26 Apr 2023 15:10:24 +0200
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Willy Tarreau <w@....eu>
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Daniel Almeida <daniel.almeida@...labora.com>,
        wedsonaf@...il.com, ojeda@...nel.org, mchehab@...nel.org,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

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@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists