Le 09/02/2016 11:38, Pekka Paalanen a écrit :
On Tue, 9 Feb 2016 01:11:48 +0100
Benoit Gschwind <[email protected]> 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.
no, I didn't thinked that design, you can have several backend in the
option3 with :
- banckend_handler * load_aaa_bakcend (provided by libbackendaaa)
- banckend_handler * load_bbb_bakcend (provided by libbackendbbb)
you can link both and select the desired backend, I did this kind of
thing in my proposed patch.
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.
Ok, I was not aware of this direction, now it's clear and I agree, I
found a compromise between option 2 and 3, I leave you to check my
submitted patch.
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
_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
