<div dir="ltr"><div>True, but it's better than nothing.<br><br>Well, I guess systemd-networkd doing basic things will have to wait on kdbus :-)<br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 3:32 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">1;3802;0cOn Tue, 03.02.15 14:38, Charles Devereaux (<a href="mailto:systemd@guylhem.net">systemd@guylhem.net</a>) wrote:<br>
<br>
> On Tue, Feb 3, 2015 at 2:29 PM, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>><br>
> wrote:<br>
><br>
> > I am pretty sure signals are not a particularly good interface for<br>
> > this. We should add a proper bus API for this one day, but this kinda<br>
> > has to wait until kdbus is a done deal, since networkd runs in early<br>
> > boot, and dbus-daemon is not available in early boot.<br>
><br>
> Which would be a good usecase for signals (until kdbus happens, which might<br>
> take some time)<br>
<br>
</span>Signals are asynchronous, which makes them a lot less useful to use,<br>
since you cannot wait resonably for completion the operation you request.<br>
<div class="HOEnZb"><div class="h5"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</div></div></blockquote></div><br></div>