| Age | Commit message (Collapse) | Author |
|---|
|
Unfortunately a different cleanup function is necessary per type,
because cap_t** and char** are incompatible with void**.
|
|
Even if the lower-leveld dbus1 protocol calls it "serial", let's expose
the word "cookie" for this instead, as this is what kdbus uses and since
it doesn't imply monotonicity the same way "serial" does.
|
|
Due to this patch, message dump (for message which includes boolean
type) is more consistent with dbus-send (which display true/false
instead of yes/no for boolean). It's only simple 'cosmetics change'.
** For dbus-send **
dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply / org.freedesktop.DBus.NameHasOwner string:org.freedesktop.login1
method return sender=org.freedesktop.DBus -> dest=:1.97 reply_serial=2
boolean true
** For libsystemd-bus (without this patch) **
‣ Type=method_call Endian=l Flags=0 Version=2 Serial=8
Destination=org.freedesktop.DBus Path=/org/freedesktop/DBus Interface=org.freedesktop.DBus Member=NameHasOwner
MESSAGE "s" {
STRING "org.freedesktop.login1";
};
‣ Type=method_return Endian=l Flags=1 Version=2 Serial=51 ReplySerial=8
Sender=:1.59 Destination=:1.67
UniqueName=:1.59 WellKnownNames={org.freedesktop.DBus}
MESSAGE "b" {
BOOLEAN yes;
};
For me true/false seems to be better readable than yes/no for BOOLEAN.
|
|
- Add space between if/for and the opening parentheses
- Place the opening brace on same line as the function (not for udev)
From the CODING_STYLE
Try to use this:
void foo() {
}
instead of this:
void foo()
{
}
|
|
(uint32_t) -1
Serial=4294967295 field in message dump generated by bus_message_dump()
function for synthetic messages isn't good readable.
|
|
|
|
|
|
This way we can unify handling of credentials that are attached to
messages, or can be queried for bus name owners or connection peers.
This also adds the ability to extend incomplete credential information
with data from /proc,
Also, provide a convenience call that will automatically determine the
most appropriate credential object for an incoming message, by using the
the attached information if possible, the sending name information if
available and otherwise the peer's credentials.
|
|
|
|
|
