Remove double semicolon at the end of line Reviewed-by: Pavel Březina <pbrezina@redhat.com>

TESTS: Fixing of 'const' warnings in sbus tests Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

sbus_codegen_tests: Use portable definition of large constants There were warnings on 32 bit architecture related to 64bit integer constants. /home/build/sssd/src/tests/sbus_codegen_tests.c:257: warning: integer constant is too large for ‘long’ type /home/build/sssd/src/tests/sbus_codegen_tests.c:259: warning: integer constant is too large for ‘long’ type INT${N}_C(value) are defined in the standard c99 Reviewed-by: Michal Židek <mzidek@redhat.com>

sbus_codegen_tests: Suppress warning Wmaybe-uninitialized There is a warning with gcc 4.8 src/tests/sbus_codegen_tests.c:1131:18: warning: 'exp_values' may be used uninitialized in this function [-Wmaybe-uninitialized] const char **exp_values; ^ Reviewed-by: Pavel Březina <pbrezina@redhat.com>

sbus codegen tests: free ctx Memory context was not freed therefore we got stuck in tevent loop that mocks D-Bus. Resolves: https://fedorahosted.org/sssd/ticket/2759 Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

tests: Move N_ELEMENTS definition to tests/common.h Avoids code duplication Reviewed-by: Pavel Březina <pbrezina@redhat.com>

sbus: add a{sas} get invoker Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sbus codegen: do not prefix getters with iface name Prefixing getters with C name of the interface is just redundant since it is the same as the name of the structure that contains those fields. The following structure: struct test_pilot { $type test_pilot_get_name; } changes to: struct test_pilot { $type get_name; } Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sbus: support org.freedesktop.DBus.Properties Bring back org.freedesktop.DBus.Properties with support of multiple interfaces on single object path. Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sbus: support multiple interfaces on single path This patch removes the old message handler which is replaced with a new one that supports multiple interfaces registered on single object path. A hash table is used to store registered object paths and their interfaces. When an entry or the table itself is destroyed, registered object path is unregistered through delete callback. It temporarily removes support of Introspect and Properties standard D-Bus interfaces and disables unit tests of those interfaces. The support is brought back by following patches. Resolves: https://fedorahosted.org/sssd/ticket/2339 Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sbus: add new iface via sbus_conn_register_iface() Rename sbus_conn_add_interface() to sbus_conn_register_iface() and remove sbus_new_interface() calls since it is just one more unnecessary call outside the sbus code. The function sbus_new_interface() is made static and used directly in sbus_conn_register_iface(). The name was chosen to better describe what the function is doing. That it registers an interface on a given object path. The same interface can be used with different paths so it is not really about adding an interface. Preparation for: https://fedorahosted.org/sssd/ticket/2339 Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>

sbus_codegen_tests: free memory context The memory context was not freed and therefore a destructor that closes connection to D-Bus and performs cleanup task was not executed. Resolves: https://fedorahosted.org/sssd/ticket/2347 Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

TESTS: check dbus mock result Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

TESTS: check allocation result Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

SBUS: Implement org.freedesktop.DBus.Properties.GetAll for primitive types This patch implements the GetAll method of the org.freedesktop.DBus.Properties interface by iterating over the available getters and putting all the results into a single getter. The patch includes a unit test that exercies all currently supported array types. Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

TEST: fix warning in sbus_codegen_tests Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

SBUS: Return / if an object path getter returns NULL Reviewed-by: Stef Walter <stefw@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com>

SBUS: Return empty string if a string getter returns NULL 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>

SBUS: Implement org.freedesktop.DBus.Properties.Get for primitive types 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>

TEST: Some macros aren't defined in older version of check. src/tests/sbus_codegen_tests-sbus_codegen_tests.o: In function `eject_handler': tests/sbus_codegen_tests.c:229: undefined reference to `ck_assert_uint_eq' tests/sbus_codegen_tests.c:235: undefined reference to `ck_assert_uint_eq' tests/sbus_codegen_tests.c:239: undefined reference to `ck_assert_uint_eq' src/tests/sbus_codegen_tests-sbus_codegen_tests.o: In function `test_marshal_basic_types': src/tests/sbus_codegen_tests.c:446: undefined reference to `ck_assert_uint_eq' src/tests/sbus_codegen_tests.c:449: undefined reference to `ck_assert_uint_eq' src/tests/sbus_codegen_tests-sbus_codegen_tests.o: src/tests/sbus_codegen_tests.c:451: more undefined references to `ck_assert_uint_eq' follow collect2: ld returned 1 exit status make[3]: *** [sbus_codegen_tests] Error 1 Macro ck_assert_uint_eq was added in check-0.9.10 Resolves: https://fedorahosted.org/sssd/ticket/2319 Reviewed-by: Michal Židek <mzidek@redhat.com>

sbus_codegen_tests: Add test case type-safe handler args 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.

sbus: Add type-safe DBus method handlers and finish functions 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.

tests: Don't set the check fork mode explicitly Instead, let the user pick the fork mode with CK_FORK variable (see info check) Reviewed-by: Sumit Bose <sbose@redhat.com>

sbus: Refactor how we export DBus interfaces Most importantly, stop using per connection private data. This doesn't scale when you have more than one thing exporting or exported on a connection. Remove struct sbus_interface and expand sbus_conn_add_interface() function. Remove various struct sbus_interface args to connection initialization functions and make callers use sbus_conn_add_interface() directly. The old method was optimized for exporting one interface on a connection. We'll have connections that export zero, one or more interfaces. To export an interface on a DBus server, call sbus_conn_add_interface() from within the sbus_server_conn_init_fn. To export an interface on a DBus client, call sbus_conn_add_interface() after sbus_new_connection() returns. As before struct sbus_interface represents an object exported via DBus. However it is now talloc allocated. One can set instance data on the struct sbus_interface. This instance data is passed to the various handlers and used in their implementation. However, we now have type safe interface exporting in the various high level sss_process_init() sss_monitor_init() and so on. Introspection support was not in use, and is now gone until we implement it using the metadata (future patch). Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

sbus: Add struct sbus_request to represent a DBus invocation struct sbus_request represents a request from a dbus client being handled by a dbus server implementation. The struct contains the message, connection and method (and in the future teh property) which is being requested. In the future it will contain caller information as well. sbus_request is a talloc memory context, and is a good place to attach any allocations and memory specific to the request. Each handler accepts an sbus_request. If a handler returns EOK, it is assumed that the handler will finish the request. Any of the sbus_request_*finish() methods can be used to complete the request and send back a reply. sbus_request_return_and_finish() uses the same argument varargs syntax as dbus_message_append_args(), which isn't a great syntax. Document it a bit, but don't try to redesign: The marshalling work (will follow this patch set) will remove the need to use varargs for most DBus implementation code. This patch migrates the monitor and data provider dbus code to use sbus_request, but does not try to rework the talloc context's to use it. Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

sbus: Generate constants from interface definitions 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>

sbus: Add sbus_vtable and update codegen to support it 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>

sbus: Add meta data structures and code generator 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>