Plan for libweston backend configuration?
bryce at osg.samsung.com
Fri Feb 26 21:37:59 UTC 2016
To followup Pekka's recent libweston thread, here's the next actions it
looks like we should take?
a. Revert 5ffbfffa
b. Land https://patchwork.freedesktop.org/patch/67547/, which covers
the drm-backend. (Is this patch proposal good as is, or would it
benefit from any additional review?)
c. Defer the two alternative options for now
d. Review/update wayland-backend and x11-backend to comply
This establishes Giulio's "Well Defined Structs" approach for
configuring libweston backends. This uses versioned structs for
communicating parameters with the backends.
If no one raises an objection to this plan, I can tackle (a), (b) and
(c) myself directly. For (d), offhand it appears they at least need to
add the structure versioning support, but might be suitable to consider
landing after that?
A couple of more sophisticated solutions were proposed and evaluated,
but it feels like our requirements here are modest, and so simpler is
probably better. Things aren't cast in stone here and we can always
move to something more advanced later if conditions warrant it.
In mind of this, here are the assumptions that are leading us to this
choice. In the future if these assumptions fail to hold adequately,
then this design should be re-evaluated.
1. libweston has no stability promises, and won't for a long time, and
it is and will remain parallel installable. We are freely able to
redo tomorrow any bad decisions we make today.
2. New options will be appended to the the struct, which will avoid ABI
3. The struct is versioned, so if we do need to break ABI for some
reason, we can and backends can thereby check and verify their
4. Configuration needs by the backends are on the tame side, mostly
just involving basic data types (strings, ints, etc.)
5. Backend configuration is internal to the backend. End users won't
be exposed to it, and only backend developers will need to tinker
with these things.
6. Additions of or changes to configuration parameter definitions are
going to be done by developers who are either part of the Wayland
development community, or will be sending all of their changes to
7. All libweston backends will be living in the weston repository. We
do not provide support for third-party backends.
It's probably non-fatal if we periodically violate one or two of these
assumptions, but if we get beyond that it should be a cue to revisit our
So far, two other alternatives were considered; here are the key design
A. Opaque Structs
This still uses structs for sharing configuration parameters but the
structs are hidden as internal details. The backend instead uses
function calls to fill in parameters.
While this does decouple things a bit and avoid ABI breakge on
structure definitions, this requires coding and maintaining an array
of backend-specific functions, which bring their own API breakage
This is essentially an incremental enhancement of the "Well Defined
Structs" scheme, so would be straightforward to upgrade to later.
Establishes a key/value backend config API, with separate
getter/setter calls for different config item data types. Backends
then call these getters to retrieve configuration variables.
This system includes provision for sections and default values.
This is certainly a much more flexible system, but many of the same
problems will exist when configuration parameters change. Just that
instead of erroring at the API/ABI layer it breaks at the
parser/configuration layer. Shifting to this lower level means
errors may get detected later on, or may be missed entirely, where a
broken struct will be more highly visible.
Alternative A might be worth considering if we start seeing
proliferation of backend options, or if the configuration settings start
going beyond basic types.
Alternative B could become more convenient if we need to expose options
to end-users or if we start seeing third-party backends.
More information about the wayland-devel