Switching to a FFI-compatible representation

[yilinwei]

Hi,

Recently I've been doing some work with GPU libraries in ocaml and came across this package. It's really cool, but unfortunately libvulkan and such depend directly on libwayland-client directly, so it's not possible to pass in the ocaml representation of wl_proxy into the various functions.

I'm currently binding the libraries via ctype and was wondering whether you'd be amenable to switching this library to an FFI-compatible representation under the hood?

Many thanks,

Yilin

[talex5]

I think it would be better to make a separate project for libwayland bindings and keep this one as pure OCaml. Ultimately, I want to remove as much C code from my desktop stack as possible. I don't know enough about GPU stuff to know how to fix the libvulkan problem, but I hope to find out one day!

[yilinwei]

Right, I totally understand; I will start a separate project with the C bindings then.

Just for posterity, I will summarize the issues in a little more depth:

1. GPU libraries such as libvulkan, wgpu usually require passing in a wl_surface and wl_display to bind to wayland correctly
2. Under the hood they are dependent on libwayland-client and will call various requests on the interfaces and methods such as wl_display_dispatch
3. This is only an issue when interfacing directly with C libraries - everything else should be fine

Theoretically, since most of these libraries dynamically load libwayland-client I believe that it might be possible to expose a C-FFI interface for a pure ocaml library (so libvulkan, etc...would call into ocaml instead), especially since most of the proxies are just pointers. It would mean the semantics of the ocaml library would have to be the same as the c library though.

[yilinwei]

I learned recently that there might be a way to do this via the dmabuf extension.

libvulkan would still need to be used, or something similar, but the wayland layer could be done in pure ocaml.

[DemiMarie]

My understanding is:

• Clients almost always need to use the C libwayland-client, as otherwise GPU acceleration won’t work. dmabuf can be used as a workaround.
• Servers do not need to use the C library.

[DemiMarie]

I think it would be better to make a separate project for libwayland bindings and keep this one as pure OCaml. Ultimately, I want to remove as much C code from my desktop stack as possible. I don't know enough about GPU stuff to know how to fix the libvulkan problem, but I hope to find out one day!

You won’t be able to, sadly.

Mesa contains not only OpenGL and Vulkan implementations, but also a complete compiler stack and drivers for many different GPUs. These drivers are significantly more complicated than the corresponding kernel-mode drivers, and the kernel-mode drivers are already quite large. Furthermore, many of the drivers in Mesa were developed by reverse engineering GPUs for which there is no public documentation. In short, reimplementing Mesa simply isn’t practical, and OCaml’s heavyweight runtime and limited interoperability with C mean that using OCaml in Mesa isn’t an option either. Mesa has already begun to use Rust, which provides memory safety without needing a heavyweight runtime and with much better C interoperability.

The use of C in Mesa is also much less problematic than one would expect, because (unless WebGL or WebGPU are involved) Mesa doesn’t deal with untrusted input. The only exception is buffers, but those don’t get parsed or otherwise processed, so they aren’t substantial attack surface. It might be possible for a malicious Wayland compositor to exploit Mesa, but that is almost certainly outside of Mesa’s threat model because the compositor is almost always trusted.

A much better solution is to provide a build-time switch to choose between a pure-OCaml implementation of the Wayland protocol and a wrapper around the system C libraries. Clients will enable this switch so that they can use C libraries that require this. Servers, on the other hand, do not need to use the Wayland C libraries at all! This is because they generally implement linux-dmabuf themselves, rather than relying on Mesa to do it for them. Since the client generally trusts the server but not the other way around, this is enough to provide the security benefits.