[PATCH wayland 0/4] Untangle the symbol export duplication

[Emil Velikov]

Hi Pekka,

Huge thanks for the input.

On 14 September 2016 at 14:35, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 30 Aug 2016 18:24:18 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> Hi all,
>>
>> For a while I've noticed that on mesa side we have few providers of the
>> wl_drm_interface symbol and literally all our 'wayland binaries' are
>> linked against both the client and server wayland libs.
>>
>> After having a look, it seems that:
>>  - the server exposes the interface symbols for 'inheritance' purposes,
>> thus other servers can build upon these primitives while designing their
>> own protocols (interfaces ?).
>
> I have no idea what that means. wl_drm is private to Mesa.
>
> You are not supposed to use wl_drm in your apps, and *no-one* is
> supposed to build on it by any other way than copying the XML file and
> renaming everything. The recommended way would be to start writing XML
> from scratch though.
>
The wl_drm* symbols are what brought me here. AFAICT all the
information/discussion is generic and not specific to it.

See below for more.

>>  - at the same time the client needs to have a reference to the
>> interface symbol in order to register an instance of said interface.
>
> Anyway, those details don't really matter at all, see below.
>
>> This means that if the "wrong" symbol gets picked at runtime and the
>> client does not correctly manage older versions in its
>> .registry_handle_global function (yes we have a case or two of those in
>> the wild) things will end up horribly wrong.
>>
>> I think that a better option would have been to distinguish the two
>> (call one instance or the other singleton) and let the scanner attribute
>> for the name difference. Regardless of that is that it's too late to
>> change things since this would lead to breaking the ABI.
>>
>> One way around it to update the scanner to provide newer symbols and
>> annotate the old ones as deprecated. This way when/if we break the ABI
>> we can untangle things. One day...
>>
>> Does the above sound about right - can anyone let me know if I'm loosing
>> the plot ?
>>
>> That said, I've went ahead and removed duplication where possible - by
>> folding the util symbols into libwayland-util. Please check with patch 3/4
>> how compatibility with existing and new users is be preserved.
>
> Actually, the <foo>_interface symbols are not meant to be exported *at
> all*. But there is a catch that is the source for all the confusion.
>
> For historical reasons, libwayland-server and libwayland-client are
> designed to export the wl_*_interface pointers, because libwayland
> ships the headers generated from wayland.xml.

> The headers cannot work
> if something does not provide the symbols from the generated
> wayland-protocol.c file.
Having a dull moment - what do you mean with the above ? How can
headers "work" or "not work" ?

> IMHO and in hindsight, this was a mistake - we
> should have installed only the XML file and require everyone to
> generate their own wayland.xml bindings to keep things consistent. But,
> it's done, and now it is API and ABI, so we cannot change that.
>
That may have been a good idea indeed.

> That is the reason why wayland-scanner emits all the WL_EXPORTs in the
> *-protocol.c file. IMO it really should not do that, except for
> wayland.xml itself only when building libwayland.
>
> It's an unfortunate accident that all libs using Wayland extensions
> from wayland-protocols or anywhere are exporting the *_interface
> symbols. There is really no need for that as I see. If two pieces of
> software use the same extension, they can just (generate and) build in
> their own copies of the *-protocol.c file.
>
Note: I'll be using protocol and interface interchangeably.

Here's my take on it:
Server foo implements protocol A which builds on top of the core
wayland primitives/interfaces X and Y.
For linking purposes server foo will depend on
libwayland-{server,client} to provide the {X,Y}_interface symbols.

Similarly on the client foo side, one needs to know the specifics of
the interfaces A, X and/or Y in order to register/instantiate them.
Which in itself, pulls the link time dependency of
libwayland-{server,client}. With the latter being the recommended one
afaict.

The only way around this would be to have all the protocol A, X and Y
code statically linked inside both client/server foo. Which in itself,
will cause binary bloat. From memory we're talking about ~20K for the
core wayland ones. That is 20K for each binary that uses wayland -
surely less than ideal.

> Libwayland has been written to cope just fine with multiple copies of
> interface definitions, or it at least should.
>
Can libwayland cope with clients which do not check versions and
always assume that vX will be present ? I believe not, yet again I'm
not sure if one can really achieve that. Speaking of which I should
really send a patch or two to fix things :-\

>
> I would seriously suggest that we make wayland-scanner *not* emit any
> WL_EXPORTs for the *-protocol.c file if at all possible. I would like
> that to be the default, while libwayland build would opt-in for the
> exports.
>
> Can we do that, or would it break any ABI we actually care about?
>
How will one resolve the dependencies of the now exported _interface
symbols at link time ?

Hiding the interface symbols from libwayland-{server,client} will lead
to a massive ABI break, since effectively everything (that I've
looked) which uses wayland depends on a selection of those.

"Everything" being: mesa (gbm, egl, vulkan), webkit2gtk,
KF5/kwin/kscreen*, weston binaries, Qt wayland integration, mpv, vaapi
(front end and drivers).

Regards,
Emil