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>
In-Reply-To: <136035a4-26df-1c14-e51e-406b4ee5fe33@xs4all.nl>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Tue, 11 Apr 2023 14:02:17 +0200
Message-ID: <CANiq72kzgopREcNcAnjCBk2u9b9cJ4f_jPix6LWYSkcOV5kubw@mail.gmail.com>
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
To:     Hans Verkuil <hverkuil@xs4all.nl>
Cc:     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 Tue, Apr 11, 2023 at 9:51=E2=80=AFAM Hans Verkuil <hverkuil@xs4all.nl> w=
rote:
>
> One of my main concerns here is time: as subsystem maintainers we can bar=
ely
> keep up with all the incoming patches. Introducing support for a new lang=
uage
> would add only more pressure. Even though these are mainly bindings (as I
> understand it), this would still require that every change to a C kAPI is
> duplicated in rust, requiring someone to do that work, and have maintaine=
rs
> with enough rust knowledge to verify it.

Indeed, that is one of the main costs.

One potential solution is to have somebody step up as the maintainer
of the Rust side (e.g. the author of the abstractions).

Of course, that will not make the work go to zero, since there still
needs to be some degree of communication even if the new maintainer
does all the Rust side work, but it may make it feasible, especially
if the abstracted parts of the C API do not change too frequently.

It is also an opportunity for existing maintainers to see how the Rust
side would work meanwhile the work gets done, and potentially a chance
to get a new maintainer involved with the whole subsystem in the
future.

Some subsystems may want to give that maintainer a different
`MAINTAINERS` entry, e.g. as a child subsystem that sends PRs to the
main one and may be marked as "experimental". This is also a way to
see how the new abstractions work or not, giving maintainers more time
to decide whether to commit to a Rust side or not.

I don't mean to say it would be doable for the media subsystem, but
please consider it.

Cheers,
Miguel