Dream: Backward compatible clean-up of libwayland-server ABI
In !299 @emersion proposed an approach to stop using the event loop API offered by libwayland-server. The event loop API is seen as not really belonging in libwayland-server, but due to library ABI stability promises, we cannot drop it and we cannot even turn it into non-working stubs.
After my comment in there we discussed in IRC about what could or should be done, but came to the conclusion that we don't have a clear goal, significant advantages from it, nor people willing to put in the work.
Since then, I remembered the other things I'd like to drop from libwayland-server. So here is a more complete list I'd like to get rid of:
- the event loop API
- libffi based C bindings
- any symbol that is duplicate with libwayland-client
The event loop API requires the community to maintain an ad hoc event loop library and port it to other OSs, while there already are portable event loop libraries that do the job much better. We need to make sure the server library allows using those event loop libraries without bundling all Wayland clients under a single aggregate fd (epoll fd). It practically works already, with some inconvenience.
Libffi is not really necessary. Only the old C language bindings use it, all other language bindings use the more recent ABI which has no need for libffi. The trade-off is different code generation from XML. We should be able to have another C language bindings generator using the same ABI as all other language bindings and get rid of libffi. Even though this requires different code generation, I believe the generated API could be identical to the existing generated C API, making compositor migration much easier, unless we actually want to change that API.
Personally I see the built-in
wayland.xml symbols as a slight mistake. No other language bindings than C can benefit from them, it is different from any Wayland extension handling, and it causes symbol conflicts between libwayland-server and libwayland-client. We should just require all user projects to generate
wayland.xml bindings the same way they generate any other extension bindings. Aside from potential symbol conflicts, I believe this is already possible.
I'm not sure if there are any other kind of symbol that is duplicated with between libwayland-server and libwayland-client, but if there is, they would be best removed, or moved into a base library pulled in by both client and server libraries.
We have issues with the shared
wl_shm implementation. One is the need to handle SIGBUS in a shared library, which is ugly and painful at best. The other are questions around validating shm buffer parameters, particularly around pixel formats vs. storage, so that the given storage is guaranteed to fit the whole image the client is claiming it to hold. This requires detailed information about the pixel formats, which is awkward to add and maintain in libwayland-server, and it would forbid compositors from supporting new pixel formats until libwayland-server gets updated, if libwayland-server actually did proper validation.
How could all that be pulled off without breaking anything and offering as gradual as possible migration path to compositors?
My proposition is to define a new library:
libwayland-server2.so. This is not Wayland 2.0, but just a second iteration of the server library.
All ABI removed in
libwayland-server2.so will remain in
libwayland-server.so and keep on working. The old
libwayland-server.so shall be re-implemented by delegating to
libwayland-server2.so. IOW, move all the good parts of old
libwayland-server2.so with perhaps a better ABI, and make new
libwayland-server.so call those. Literally nothing will change for compositors,
libwayland-server.so will just automatically pull in
libwayland-server2.so. This design ensures that if a compositor has components using both
libwayland-server2.so, things will keep working. That should help with gradual migration.
Each compositor project can then individually decide if and when they want to migrate to
libwayland-server2.so and drop the usage of
libwayland-server.so. There are caveats: projects depending on
EGL_WL_bind_wayland_display may not be able to ever migrate. The same applies for any compositor-side library that will not or cannot migrate to
libwayland-server2.so. Libraries that already use the event loop API would have problems migrating.
We have two language bindings ABI: the old libffi-based one specific to C will remain in
libwayland-server.so, and the more generic used by all other language bindings will move into
libwayland-server2.so as-is, to remain available via
libwayland-server.so pulling in
libwayland-server2.so. Hmm, this might cause problems with libwayland-client... that would need more investigation.
If there is desire the change the API of the Wayland bindings for C as well, that would be a separate project. If the ABI that language bindings are implemented on top of does not need changes, this would be completely independent from the
One should also consider what happens with libwayland-client. Does it cause problems to this plan, do we need even more shared libraries, and what if you just wanted to combine both server and client libraries into a single library to eliminate any duplicated symbols for good?
What's the worth of this if a drop-in reimplementation in Rust will happen? Or would it perhaps be much better to reimplement
libwayland-server2.so in Rust, and leave all the uglies to the old C
Obviously this is complicated.
Disclaimer: Personally right now I have no real need for any of this, and I have no reason or opportunity to spend any effort to push this forward in any future I can foresee. I will probably not be available to even review proposals. I just wanted to save these ideas and discussions for posterity.