Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230406215615.122099-1-daniel.almeida@collabora.com>
 <136035a4-26df-1c14-e51e-406b4ee5fe33@xs4all.nl> <CANiq72kzgopREcNcAnjCBk2u9b9cJ4f_jPix6LWYSkcOV5kubw@mail.gmail.com>
 <ZDVXbw/097jvjKvK@1wt.eu> <CANiq72n8ZV_bs_xp5rNtar4vmfknJtZg4OHJW6vHuhVFmGs8mg@mail.gmail.com>
 <ZDWQXDRknzFhngyk@1wt.eu> <CANiq72n=s23naD4-UkmuLesekDTf4b5bsmWc+fYANYPq+X1R9w@mail.gmail.com>
 <ZDXCeKkbPoZi5k6t@1wt.eu> <CANiq72kceQ8aWk7mtB4MoepUr3hNzF34d=DfVzdeCLGRAZwE6g@mail.gmail.com>
 <0da49a77-14d8-cb9d-e36d-985699746b6b@metux.net>
In-Reply-To: <0da49a77-14d8-cb9d-e36d-985699746b6b@metux.net>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Wed, 26 Apr 2023 18:05:06 +0200
Message-ID: <CANiq72nnOGLA1bm8n=e9_NDozNUAWvs2ModigR1xu_Qij08Eiw@mail.gmail.com>
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
To:     "Enrico Weigelt, metux IT consult" <info@metux.net>
Cc:     Willy Tarreau <w@1wt.eu>, Hans Verkuil <hverkuil@xs4all.nl>,
        Daniel Almeida <daniel.almeida@collabora.com>,
        wedsonaf@gmail.com, ojeda@kernel.org, mchehab@kernel.org,
        rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-media@vger.kernel.org, kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Apr 26, 2023 at 3:36=E2=80=AFPM Enrico Weigelt, metux IT consult
<info@metux.net> wrote:
>
> The tricky question is: how much time will be needed ?

That depends on how fast Rust grows in the kernel itself, so I would
expect it will be a self-regulating feedback loop.

> Personally, I'm too overloaded for diving deeper into Rust anytime soon.

That is fine, one can always wait a bit more to see how things evolve.

Now, if somebody wants to use Rust in a subsystem you maintain, then
you can always consider letting them maintain that part. As I
mentioned above, that can be a quite nice approach to learn Rust on
the side and recruit new future maintainers/reviewers.

> 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)

I am not sure what you mean, but `rustc` uses LLVM for codegen, and
`rustc_codegen_gcc` and GCC Rust are coming.

If you mean on the developer UX side, for the kernel at least, you
still call `make` as usual. Of course, some things differ here and
there, and there are still things to improve, but it is fairly usable
even at this stage.

We are also working on introducing some features that the C side does
not have yet. So there can be upsides on this regard, too.

> * fast-moving target (one has to be careful to expect/use the right
>    toolchain version)

This currently applies to the kernel, yes, because we require some
unstable features.

To be clear, this is something that we are working on solving,
precisely because we know it is not ideal. In any case, the decision
made was to go forward meanwhile that got solved, and it is not a
blocker for some users/companies.

> * rarely understood by traditional kernel devs

Not sure what you mean by this, but a few traditional kernel devs have
successfully picked up Rust already and are interested in increasing
their usage of it.

> * distro/build engine integration/support still pretty infant,

Most distros package Rust as explained above, which may be enough for
you depending on the distro you use.

> 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

That depends on the user/company/entity. For instance, some companies
and projects already want to use (or are using) Rust in the kernel,
because they control their toolchains.

> 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.

That is fine -- many companies and projects have different
requirements, and nobody expects everybody to enable Rust in their
kernel nor to make it a hard/unconditional requirement anytime soon
(if it ever happens).

> Ergo: the whole process of adding Rust to the Kernel needs to be done
> very, very carefully.

Indeed -- if you have particular concerns that you think have not been
addressed yet in the last 2+ years, please contact us.

> 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.

There is no effect on downstream, unless they drop support for what
they already have. But that is just like any other proposed removal.

> 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.

That would not accomplish anything except making everything more
opaque, not to mention harder for downstream users who are waiting for
things to land.

Again, if you have particular concerns, please feel free to raise
them, but please note that most of this has been discussed for a long
time and decided upon.

Cheers,
Miguel