[vlc-devel] [RFC: PATCH 1/2] libvlc: Add Rust API for writing modules in rust

Alexandre Janniaux ajanni at videolabs.io
Fri Sep 11 02:42:08 CEST 2020


Hi,

On Thu, Sep 10, 2020 at 10:36:30PM +0200, Romain Vimont wrote:
> On Thu, Sep 10, 2020 at 10:43:49PM +0300, Rémi Denis-Courmont wrote:
> > 2) Who's in charge of updating the Rust modules when the core API changes? We
> > can't expect all developers of core patches to know Rust, and know it well
> > enough to update Rust code properly. FWIW, I believe that only a minority of
> > the TC knows Rust well at this point in time even, not to speak of the broader
> > vlc-devel active membership.

We're quite a few people aiming at having rust in VLC, but
you're right to highlight this aspect. Designing a correct
solution would probably require the involvement of the TC
so as to define what is required here in clearer terms.

Like Romain mentioned it, Thomas did a lot of research in
this area, including the following (probably not exhaustive)
solutions:

 - write the rust code in contribs, export C libraries, use
   the C libraries in C modules. This is the approach taken
   for the rav1e integration that was merged, close to the
   following one too.

 - exposing C API from Rust, use both the C API from Rust
   and the VLC api in a lightweight binding C module.
   You refused this idea in the last review of the Cuesheet
   experiment though, leading to the binding of the VLC API
   into Rust.

 - expose both C API from Rust and VLC API to Rust, in
   particular so as to expose a module in C but define the
   rest of the plugin in Rust. This is this approach.

 - expose an intermediate C layer that only Rust people would
   maintain, bind this C layer to Rust and define the modules
   in Rust. This is the same kind of approach as the «lua»
   bindings, but it duplicates the work and is not really
   magic. Some modifications just cannot be ignored at the
   compatibility layer and need to be brought into the rust
   modules, for example if deleting a functionality.

One of the main issue is to ensure that a modification in the
C API won't break the assumptions in the Rust bindings, since
others would probably be catchable by the CI.

This problem can probably also be solved by a smarter
integration process but I'm not enough experimented to know
what would not work in this case.

> One major goal of these experiments is to find a solution which allows
> both to create Rust modules easily and does not require to update Rust
> code too often.
>
> A possible compromise is to expose a specific "simplified" API, stable,
> in C, wrapped in Rust, to expose only specific features of the real core
> API.
>
> Thomas Guillem wrote:
>
> > A Rust demux module could have a demux() function that read data via
> > vlc_stream and send the result via some rust callbacks. The C module
> > wrapper is then propagating these callbacks to es_out controls.
>
> https://mailman.videolan.org/pipermail/vlc-devel/2020-August/136347.html
>
> That way, the core API changes should not require to update the Rust
> bindings and modules often (updating the C part of the simplified API to
> maintain the stable Rust API should be sufficient).
>
> (cf full discussion:
> https://mailman.videolan.org/pipermail/vlc-devel/2020-August/thread.html#136231)
>
> Regards


Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list