[systemd-devel] libsystemd-bus and glib port - problem with GVariant Serialization
Lukasz Skalski
l.skalski at partner.samsung.com
Thu Jan 2 01:52:44 PST 2014
Hi,
I'm working on port gdbus natively onto kdbus. I've already done most
part of this project - Hello, RequestName, ReleaseName, List*, Get*,
NameHasOwner and others org.freedesktop.DBus methods are implemented and
works great, what is still missing at this moment are AddMatch and
RemoveMatch, but it shouldn't be problem and it will be done as soon as
I solve the current problem with serialization. So...
In glib, I changed header protocol version to '2' (header already has
field with information about length of the additional header fields
array - everything is as described it in GVARIANT-SERIALIZATION
document), but if I try send method call from my gio test apllication to
second application (which uses libsystemd-bus) I get "Bad message" from
libsystemd-bus. It is probably problem with serialization in my glib...
I did some research. I prepared two applications - first uses my glib
with kdbus interface, second uses libsystemd-bus. Both applications
invoke the same method call as below:
1) Application 1 (GLIB)
result = g_dbus_connection_call_sync (connection,
"org.freedesktop.systemd.test",
"/",
"org.freedesktop.systemd.test",
"Slow",
NULL,
NULL,
G_DBUS_CALL_FLAGS_NONE,
-1,
NULL,
&error);
2) Application 2 (LIBSYSTEMD-BUS)
r = sd_bus_message_new_method_call(
bus,
"org.freedesktop.systemd.test",
"/",
"org.freedesktop.systemd.test",
"Slow",
&m);
if (r < 0) {
log_error("Failed to allocate method call: %s",
strerror(-r));
goto finish;co je
}
sd_bus_message_unref(reply);
reply = NULL;
r = sd_bus_call(bus, m, 0, &error, &reply);
After that I added hexdump() function to libsystemd-bus and compared the
same method invocation in glib and libsystemd-bus after serialization:
1) Application 1 (GLIB)
0000: 6c 01 00 02 00 00 00 00 02 00 00 00 6d 00 00 00 l...........m...
0010: 01 01 6f 00 01 00 00 00 2f 00 00 00 00 00 00 00 ..o...../.......
0020: 03 01 73 00 04 00 00 00 53 6c 6f 77 00 00 00 00 ..s.....Slow....
0030: 02 01 73 00 1c 00 00 00 6f 72 67 2e 66 72 65 65 ..s.....org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 00 00 06 01 73 00 1c 00 00 00 test......s.....
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 00 00 systemd.test....
2) Application 2 (LIBSYSTEMD-BUS)
0000: 6c 01 00 02 00 00 00 00 01 00 00 00 73 00 00 00 l...........s...
0010: 01 00 00 00 00 00 00 00 2f 00 00 6f 00 00 00 00 ......../..o....
0020: 03 00 00 00 00 00 00 00 53 6c 6f 77 00 00 73 00 ........Slow..s.
0030: 02 00 00 00 00 00 00 00 6f 72 67 2e 66 72 65 65 ........org.free
0040: 64 65 73 6b 74 6f 70 2e 73 79 73 74 65 6d 64 2e desktop.systemd.
0050: 74 65 73 74 00 00 73 00 06 00 00 00 00 00 00 00 test..s.........
0060: 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.freedesktop.
0070: 73 79 73 74 65 6d 64 2e 74 65 73 74 00 00 73 0c systemd.test..s.
0080: 1f 47 6f 00 00 00 00 00 .Go.....
As you can see above, path name, interface name and others string are in
the same place. Problem is with signature positions. Any ideas on what
could be causing the problem?
BR,
--
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
l.skalski at partner.samsung.com
More information about the systemd-devel
mailing list