linux-kernel - Re: [PATCH 0/6] Initial Rust V4L2 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230426003210.GA31260@pendragon.ideasonboard.com>
Date:   Wed, 26 Apr 2023 03:32:10 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
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 Tue, Apr 11, 2023 at 02:02:17PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 9:51 AM Hans Verkuil <hverkuil@...all.nl> wrote:
> >
> > One of my main concerns here is time: as subsystem maintainers we can barely
> > keep up with all the incoming patches. Introducing support for a new language
> > 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 maintainers
> > with enough rust knowledge to verify it.

Another issue is that the V4L2 subsystem is plagued with lifetime
management problems. I don't think rust bindings could be safely written
for the MC and V4L2 subdev in-kernel APIs at the moment for instance.
Sakari recently attempted to fix some of those issues (again), see [1].
Progress is slow on this front because V4L2 is generally understaffed.

[1] https://lore.kernel.org//20230201214535.347075-1-sakari.ailus@linux.intel.com

Now, I hope that mentioning "lifetime management problems" will be
enough to nerd-snipe a rust enthusiast or two to help fix the C code in
order to implement proper rust bindings on top ;-)

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

That would certainly be a required step, but I don't think it would be
enough. On good days I see the media subsystem as barely able to cope
with the current load, on bad days it feels it's completely collapsing.

We have homework to do when it comes to maintenance for the media
subsystem, we're doing *really* badly at the moment regarding community
management and attracting (and retaining) new core contributors. This is
a topic I really want to discuss face to face during the media workshop
in Prague (and I know that many people are looking forward to that
discussion).

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

-- 
Regards,

Laurent Pinchart