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: <20230426163512.GE18120@pendragon.ideasonboard.com>
Date:   Wed, 26 Apr 2023 19:35:12 +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,
        Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

Hi Miguel,

(CC'ing Sakari Ailus)

On Wed, Apr 26, 2023 at 06:18:35PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 26, 2023 at 2:32 AM Laurent Pinchart wrote:
> >
> > 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 ;-)
> 
> Good idea ;)
> 
> I think it is definitely a good opportunity to consider how Rust could
> fit the new design, and perhaps borrow some ideas from Rust for the
> new design, even. If you feel like a quick meeting could help on that,
> please let us know.

I think we have a fairly good view of what needs to be done, the rules
are the same regardless of the programming language and whether the
compiler or reviewers enforce them (Hans, Sakari, please feel free to
disagree). Thanks for your offer though, it's appreciated.

> > 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).
> 
> I am sorry to hear that. One idea would be offsetting the extra work
> by having the Rust person also take care of some of the C parts too.
> That way you can also potentially get them to be a full maintainer at
> some point, even if the Rust experiment does not pan out.

That's certainly something I would consider very positive. If anyone is
interested in having a look at (part of) the problem and possible
solutions, [1] is the most recent patch series posted to handle some of
the lifetime issues, and [2] is a more generic version of part of [1].

[1] https://lore.kernel.org/linux-media/20230201214535.347075-1-sakari.ailus@linux.intel.com/
[2] https://lore.kernel.org/linux-kernel/161117153248.2853729.2452425259045172318.stgit@dwillia2-desk3.amr.corp.intel.com/

> Of course, easier said than done, and managing more people always
> takes extra time, but getting more people seems to be part of the
> solution anyway, from what you say.
> 
> In any case, thanks a lot for at least considering it :)

-- 
Regards,

Laurent Pinchart