[systemd-devel] [PATCH] Log failing start conditions

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 18, 2013 at 02:47:56PM +0200, Lennart Poettering wrote:
> On Thu, 18.07.13 05:52, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > > I'd prefer if we'd solve this without the journal. Instead, I think
> > > "struct Condition" should be extended to store the most recent test
> > > result in a tri-state, i.e. negative for "untested", zero for "failed",
> > > positive for "succeeded". Then we should add bus property to the Unit
> > > interface that is an array of structs with the conditions in them,
> > > including their results.
> 
> > I've now extended the dbus api, except that 0 means untested,
> > >0 means OK, <0 means failed, in case we decide to extend failed 
> > later on.
> 
> Hmm, so thinking about this, it probably is not a good idea to expose a
> tristate as an int on the bus, but do that the same way as we expose
> enums (i.e. as strings).
> 
> We already have some generic support for tri-states in place. For
> example, there is config_parse_tristate() which parses a configuration
> boolean into a tri-state int. And we have
> bus_property_append_tristate_false() which serializes a tri-state int to
> a dbus boolean mapping both < 0 and 0 to false.
> 
> Now, in both cases the externally visible type is actually a bool, even
> if we internally distuingish three different states. For the condition
> stuff it is necessary to *actually* distuingish three states on the wire
> too. D-Bus doesn't know this natively however.
> 
> Maybe use a string and map > 0 to "t", 0 to "f" and < 0 to ""?
> 
> static inline const char* tristate_to_string(int v) {
>        return v > 0 ? "t" : 
>              v == 0 ? "f" : "";
> }
> 
> Or something like that?
> 
> Sounds a bit more future proof that way I think. 
> 
> What I am afraid of here is that if we expose tristate-as-int on the bus
> that people will actually assume -1 and 1 are the values to check for,
> even though we actually mean < 0 and > 0...
I don't see why anybody would assume that, if is is explicitly documented
(something like "The value is < 0, currently -1 is always used, but we
reserve the possibility of extending the range of values used to carry
additional information. So you should use 'state < 0' as the condition
for a failed condition.")

I'm worried that numbers are easier to carry additional data
(e.g. errno), and if strings are used, the interface will be hard to
extend without breaking users who expect "f" for failure.

Zbyszek
-- 
they are not broken. they are refucktored
                           -- alxchk