summaryrefslogtreecommitdiffstats
path: root/src/sbus/sssd_dbus_meta.c
Commit message (Collapse)AuthorAgeFilesLines
* SBUS: Fix warning declaration shadows a global declarationLukas Slebodnik2014-05-161-4/+4
| | | | | | | | | src/sbus/sssd_dbus_meta.c: In function 'sbus_meta_find_signal': src/sbus/sssd_dbus_meta.c:43: warning: declaration of 'signal' shadows a global declaration /usr/include/signal.h:101: warning: shadowed declaration is here Reviewed-by: Stef Walter <stefw@redhat.com>
* SBUS: several trivial style fixesJakub Hrozek2014-05-131-3/+6
| | | | | | | | | | In SSSD we tend to use {} brackets around single-line blocks, too to make sure we don't forget to add them should the block become larger. We also don't add a space between function name and the opening "(". Reviewed-by: Pavel Březina <pbrezina@redhat.com> Reviewed-by: Stef Walter <stefw@redhat.com>
* sbus: Add meta data structures and code generatorStef Walter2014-02-241-0/+64
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>