[PATCH weston v3] drm: port the drm backend to the new init api

[Pekka Paalanen]

On Tue, 9 Feb 2016 01:11:48 +0100
Benoit Gschwind <gschwind at gnu-log.net> wrote:

> Hello,
> 
> while I developing the option 2. I raise few questions because this 
> option explicit the fact that back-ends does not share the same API (at 
> less for the configuration). To resolve the issue I found the following 
> options:
> 
>   1. find a common configuration API (use key/value)
> 
>   2. have the following split:
>     - libweston: every thing that is not in back-ends.
>     - libbackendx, libbackendy, ... : back end implementation of 
> configuration stuff, that you must link with libweston (this is the 
> uncommon API parts of back-ends
>     - backendx.so, backendy.so, ... : the loadable (common API) part of 
> backends.
> 
>   3. have the following split:
>    - libweston: every thing that is not in backends.
>    - libbackendx, libbackendy, ... : back end are not more loadable, and 
> are linked at build, developer can drop useless back-ends.

Hi,

I understand option 2, but I do not understand how option 3 could work.

I suppose option 3 means that a compositor would be built to run just a
single backend, and you cannot choose it at runtime? We certainly do
not want to pose that kind of a limitation.

We also do not want to load more than one backend at a time to the
compositor process, because different backends pull in different
libraries and sometimes those are a significant burden. It would be sad
if a compositor that supported both DRM and X11 backends would *always*
load libX11 regardless of which it is using. It would be useless work
at start-up, and also make the dependencies of the compositor too much:
you cannot choose to install it with libs for DRM only. That would be
awkward for distributions.

About distributions, you can see the explanation on how Weston project
will be intended to be split into binary packages in a distribution in
Weston's readme.

> Maybe you have better idea, from my point of view I will prefer the 
> third one. it's not optimal in term of loading and memory because we 
> need to load all available back-ends but it's cleaner.

For the above reasons, I believe option 3 is not acceptable.

> Maybe in the option 3 we can hide the option 2 inside, that load a 
> backend.so only once it's used to save memory and loading time.
> 
> This is something I didn't foresee in my previous e-mail.

Right, so you propose we add yet another bunch of libraries, one per
backend, to be linked to by the compositor program at build time. The
benefit is that libweston.so would not export any backend-specific
symbols.

I think that is the only benefit, and the amount of code inside these
libraries would be quite small. Therefore to me the trade-off compared
to libweston.so just exporting those symbols itself is not worth it.

The summary in your previous email on the possible design choises is
still accurate in my opinion, this new idea here is just bringing more
complexity that it is worth.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160209/5b54cca2/attachment.sig>