Subject: Reasons to require platforms to link against libmirplatform

From: Andreas Pokorny <[email-masked]>
Date: Tue, 22 Sep 2015 16:58:22 +0200

Hi,
The discussions around libmirplatform has spawned another topic. Should we
require our and 3rd party loadable platforms to link against
libmirplatform. At the moment graphics platforms have to link against
libmirplatform, while input platforms may at least for now get away without
doing that.

Our current graphics platforms need symbols from libmirplatform because:
 * they might want to access program options, hence need the mir::options::
and related symbols resolved, and mir::options is the only interface for
that
 * they have to provide implementations for interfaces part of the graphics
platform ABI
 * usage of mir egl/gl classes
 * usage of udev::Monitor

I think we can resolve all of the above by duplicating the symbols through
static libraries or providing access to program settings though a purely
stdc++ interface... All except the 2nd item. As far as I understood how
runtime type information is encoded, if we want it to work for instances of
the graphics (and finally also input) platform ABI interfaces, we need to
export the typeinfo inside a shared library. And we should make sure that
all interfaces that are part of the graphics and input platform ABI get
exported in that way.

This mail was initially intended to start a discussion about whether we
need libmirplatform or not, or more specific whether we shall export
typeinfo for things like DisplayConfiguration or InputDevice to a shared
library.. But given the current plans to split out the renderer from the
platform we will soon have cases inside mir itself that will require
working runtime typeinfo. Even when there is no direct need, I see no
reason to have an exemption for input platforms.

regards
Andreas

---

From: Andreas Pokorny <[email-masked]>
Date: Tue, 22 Sep 2015 17:31:22 +0200

Hi again,

After another short round of discussion during standup we came to the
following conclusion:
 - provide a library with mir::graphics::* symbols, named
libmirplatform-graphics.so
 - reduce libmirplatform to udev::Monitor program::options and related
utilities, named libmirplatform.so
 - provide a library with mir::input::* symbols, named
libmirplatform-input.so

instead of lumping them all together in a single library.

regards,
Andreas

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 23 Sep 2015 09:39:38 +0800

As discussed yesterday, I think long term we need to get away from 
requiring drivers to link to anything at all. Because some 
vendors/lawyers require that, and specifically require that they not be 
asked to link to LGPL code. Aiming for this higher goal will also force 
us to think more deeply and build a better system...

---

From: Andreas Pokorny <[email-masked]>
Date: Wed, 23 Sep 2015 17:44:39 +0200

Hi,

On Wed, Sep 23, 2015 at 3:39 AM, Daniel van Vugt <
[email-masked]> wrote:

> requiring drivers to link to anything at all. Because some vendors/lawyers
> require that, and specifically require that they not be asked to link to
> LGPL code. Aiming for this higher goal will also force us to think more
> deeply and build a better system...

The future is now. The main motivation for this change disappeared a few
years ago. Current standard libraries seem to be able to deal with typeinfo
behind module boundaries. For now input platforms do not need to link
anything to be able to talk to a mirserver. And for now I am not continuing
that refactoring. We still might do a split of libmirplatform some time in
the future.

regards
Andreas