| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Reviewed-by: Stef Walter <stefw@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
In line with getters never returning errors, a getter should return an
empty string instead of NULL in case a string-like property in SSSD is
not set.
Reviewed-by: Stef Walter <stefw@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements type-safe getters for primitive types and their
arrays. The patch includes unit tests of all supported types and arrays
of these types.
All getter are synchronous. The getters never fail, instead, they return
a default or 'not defined' value. Making the getters synchronous and
always returning a value will make it significantly easier to implement
the GetAll method.
Reviewed-by: Stef Walter <stefw@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
| |
|
|
|
|
| |
This adds a big test case for invoking a handler with all supported
basic arguments, and constructing a reply with the same. Lots of
tedious code, but worth it to make sure things work well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type safe method handlers allow methods not to have to do tedious
unwrapping and wrapping of DBus method call messages or replies.
Arguments of the following DBus types are supported in type-safe
method handlers. In addition arrays of these are supported.
y: uint8_t
b: bool (but no arrays, yet)
n: int16_t
q: uint16_t
i: int32_t
u: uint32_t
x: int64_t
t: uint64_t
d: double
s: char * (utf8 string)
o: char * (object path)
As an exception, arrays of booleans are not supported, but could be
added later. Other more complex types could be added later if desired.
If a method has other argument types, then it must be marked as having
a raw handler (see below).
Internally each method can have a type specific invoker function which
unpacks the incoming arguments and invokes the method handler with the
correct arguments.
Each method also has a finish which accepts the type-safe out arguments
(ie: return values) and builds the reply message. Like other request
'finish' functions, these free the request talloc context, and are to
be used in place of sbus_request_finish() or friends.
Raw method handlers parse their own method arguments, and prepare their
own reply (ideally using sbus_request_finish() helpers). They can also
do strange things like have variable arguments. To mark a DBus method
as having a raw method handler use the following annotation:
<annotation name="org.freedesktop.sssd.RawHandler" value="true"/>
Raw methods do not have invokers or finish functions.
I've left all of the internal peer to peer communication using raw
method handlers. No code changes here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not strictly necessary, but avoids duplicating data
in mulitple places, and makes the interface definitions
benefit dbus callers (a little).
After applying this commit you may need to 'make clean' as
the codegen has changed.
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each interface is a vtable structure derived from
sbus_vtable, in the sense that it has an sbus_vtable
struct as its first argument. This lets us upcast the
interface vtable structure to an sbus_vtable and dispatch
to it dynamically and cleanly.
The interface metadata contains information about which
vtable offset in the interface metadata should be dispatched
to for a given function. This is a common scheme, not only
among dbus implementations, but also compiled languages.
Currently all the vtable functions are of type
sbus_msg_handler_fn. These are the handlers we are familiar
with and perform raw processing of the message. Later commits
will introduce type safe handlers that levelage compile checking
and automatic argument packing/unpacking.
Although this may seem contrived now, the remainder of the
dbus infrastructure work will build on this, including
ofd.Properties, ofd.ObjectManager, ofd.Introspect, compiler
checked type safe unpacking/packing, etc.
The codegen now generates vtable structures for each interface
along-side the metadata, and fills in vtable offsets
appropriately.
It is obviously still possible to hand-craft such vtables and
metadata if needed for a special case.
Once again examples output can be found at:
src/tests/sbus_codegen_tests_generated.h
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
|
|
These metadata structures hold the information about all the
details of a DBus interface. They are typically generated from
the canonical XML form of the DBus interface, although they
may also be hand crafted.
Add some handy functions for looking up methods, props, signals,
in the metadata of an interface. Currently lookups are just done
by looking through an array. If performance becomes an issue (ie:
very large interfaces) it would be really easy to sort things
and use bsearch().
Later commits will include some definitions using this metadata
and related functions.
DBus interfaces are defined here:
http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format
The introspection data format has become the standard way to represent a
DBus interface. For many examples see /usr/share/dbus-1/interfaces/ on a
typical linux machine.
A word about annotations. These are extra flags or values that can be
assigned to anything. So far, the codegen supports this annotation:
org.freedesktop.DBus.GLib.CSymbol
- An annotation specified in the specification that tells us what C symbol
to generate for a given interface or method. By default the codegen will
build up a symbol name from the DBus name.
It is possible to confuse the code generator into producing invalid
C code (with strange method names, for example), but the C compiler
catches such silliness right away.
Add tests testing basic features of the codegen and poking through
the metadata it creates. Also test the metadata lookup functions.
Generated code is checked in for easy discovery.
An example of the XML interface definitions can be found at:
src/tests/sbus_codegen_tests.xml
And an example of the generated header can be found here:
src/tests/sbus_codegen_tests_generated.h
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Sumit Bose <sbose@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
