On a recent merge proposal¹, Alan wrote:
>> Huh. I *guess* you could use the logging interface for detecting
display
>> configuration changes.
>
> You have that backwards. The reason we have the report interfaces is
that there are things
> that need reports from Mir that are not logging.
>
> I remember long discussions when we introduced reports about why we
didn't just log directly.
> This is an example of something that isn't logging or lttng.
I don't particularly mind using Reports as a method of system
implementation², but I think that the current social expectation
around Reports more closely matches “the various mir::report::*
interfaces we have are fundamentally debugging aids, and correct system
operation would not be impacted if we entirely removed them”.
As far as I'm aware, with the exception of ::new_configuration(), this
is currently the case.
If we *are* going to treat Reports as something that shells can
generically hook into to drive control flow we're going to need to be
more careful about the environment we call them in. For example,
currently if a shell hooks into new_configuration() and requests the
base_configuration() we'll deadlock. I've not worried about ensuring my
code doesn't hold any locks when calling into a Report, nor have I
checked that during reviews, because I've expected the Report
implementations to be roughly pure functions.
So, I'm happy for us to use Reports as a general introspection method,
but I suspect that many on the Mir team don't currently think they are,
and we'll need to change our behaviour if they are.
¹:
https://code.launchpad.net/~raof/mir/notify-shell-of-display-configuration/+merge/305189
²: Modulo the concern that, currently, this means that we don't
guarantee that debugging information is available, and a naive
implementation hooking into a report will destroy its use as a source
of post-hoc debugging information.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
