1 How we use GVariant for serializing D-Bus messages
2 --------------------------------------------------
4 We stay as close to the original dbus1 framing as possible. dbus1 has
7 1. A fixed header of "yyyyuu"
8 2. Additional header fields of "a(yv)"
9 3. Padding with NUL bytes to pad up to next 8byte boundary
12 Note that the body is not padded at the end, the complete message
13 hence might have a non-aligned size. Reading multiple messages at once
14 will hence result in possibly unaligned messages in memory.
16 The header consists of the following:
18 y Endianness, 'l' or 'B'
21 y Protocol version, '1'
22 u Length of the body, i.e. the length of part 4 above
27 When using GVariant we keep the basic structure in place, only
28 slightly extend the header, and define protocol version '2'. The new
31 y Endianness, 'l' or 'B'
34 y Protocol version, '2'
35 u Length of the body, i.e. the length of part 4 above
37 u Length of the additional header fields array
41 This has the nice benefit that the beginning of the additional header
42 fields array is aligned to an 8 byte boundary. Also, in dbus1
43 marshalling arrays start with a length value of 32bit, which means in
44 both dbus1 and gvariant marshallings the size of the header fields
45 array will be at the same location between bytes 12 and 16. To
49 Common: | E | T | F | V | Body Length | Serial | Fields Length |
51 dbus1: | ... (as above) ... | Fields array ...
53 gvariant: | ... (as above) ... | Fields Length | Fields array ...
55 And that's already it.
57 Note: on kdbus only native endian messages marshalled in gvariant may
58 be sent. If a client receives a message in non-native endianness
59 or in dbus1 marshalling it shall ignore the message.
61 Note: The GVariant "MAYBE" type is not supported, so that messages can
62 be fully converted forth and back between dbus1 and gvariant