[systemd-devel] sd-bus dynamic property table
Lennart Poettering
lennart at poettering.net
Mon May 20 09:54:37 UTC 2019
On Mo, 13.05.19 08:25, Stephen Hemminger (stephen at networkplumber.org) wrote:
> I have a simple application that does provides property table for network
> devices (maybe it would be useful for a more complete example somewhere).
> The app is more to show how to use sdbus, not to replace network manager.
>
> The next step is to add ethtool statistics. Each type of network device will have
> different set of named properties. How could this be implemented?
> So far, the only idea would be to dynamically build a vtable then
> register it?
>
>
> # busctl tree org.networkplumber.net1
> └─/org
> └─/org/networkplumber
> └─/org/networkplumber/net1
> └─/org/networkplumber/net1/interface
> ├─/org/networkplumber/net1/interface/eno1
> ├─/org/networkplumber/net1/interface/eno2
> ├─/org/networkplumber/net1/interface/ens11
> └─/org/networkplumber/net1/interface/lo
>
> # busctl introspect org.networkplumber.net1 /org/networkplumber/net1/interface/eno1
> NAME TYPE SIGNATURE RESULT/VALUE FLAGS
> org.freedesktop.DBus.Introspectable interface - - -
> .Introspect method - s -
> org.freedesktop.DBus.Peer interface - - -
> .GetMachineId method - s -
> .Ping method - - -
> org.freedesktop.DBus.Properties interface - - -
> .Get method ss v -
> .GetAll method s a{sv} -
> .Set method ssv - -
> .PropertiesChanged signal sa{sv}as - -
> org.networkplumber.net1.Interface interface - - -
> .carrier property q 1 -
> .ifindex property q 2 -
> .iflink property q 2 -
> .mtu property q 1500 -
Simon already replied to this, but let's add some further points:
dbus' object model is modelled after the object model of common
object-oriented programming languages, i.e. Java, C# and
suchlike. They generally have immutable interface definitions,
i.e. the vtables consisting of methods and properties never change,
but the implementation of them might, and objects might expose
different interfaces at the same time, in different combinations.
It's not unlike C in many ways: a C struct definition doesn't change
either, regardless what you apply it to.
Hence: you have multiple options to model what you are trying to do:
try to split things up into multiple interfaces so that you object can
implement them in varying combinations. Or simply define all
properties at all times, but define a special value (i.e. UINT64_MAX
for a uint64_t property or so) that indicates they don't actually
apply to the current object.
Lennart
--
Lennart Poettering, Berlin
More information about the systemd-devel
mailing list