Re: [PATCH libgpiod v5 0/4] dbus: add GLib-based D-Bus daemon and command-line client

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

On Mon, Aug 12, 2024 at 10:22:21AM +0200, Bartosz Golaszewski wrote:
> I'm resending it once more but with commits squashed into how they'll appear
> in git once applied upstream. I think the code is in good enough shape that
> it can now go into the master branch and any further development can happen
> from there.
> 
> Big thanks to Philip Withnall <philip@xxxxxxxxxxxxxxx> for his thorough review
> of this series. I think I addressed most of the issues pointed out.
> 
> This series introduces the D-Bus API definition and its implementation in the
> form of a GPIO manager daemon and a companion command-line client as well as
> GLib bindings to libgpiod which form the base on which the former are built.
> 
> While I split the GLib and D-Bus code into several commits for easier review,
> I intend to apply all changes to bindings/glib/ and dbus/ as two big commits
> in the end as otherwise the split commits are not buildable until all of them
> are applied.
> 
> The main point of interest is the D-Bus interface definition XML at
> dbus/lib/io.gpiod1.xml as it is what defines the actual D-Bus API. Everything
> else can be considered as implementation details as it's easier to change
> later than the API that's supposed to be stable once released.
> 
> The first two patches expose the test infrastructure we use for the core
> library and tools to the GLib bindings and dbus code. Next we add the GLib
> bindings themselves. Not much to discuss here, they cover the entire libgpiod
> API but wrap it in GObject abstractions and plug into the GLib event loop.
> 
> Finally we add the D-Bus code that's split into the daemon and command-line
> client. I added some examples to the README and documented the behavior in
> the help text of the programs as well as documented the interface file with
> XML comments that gdbus-codegen can parse and use to generate docbook output.
> 
> For D-Bus, most of the testing happens in the command-line client bash tests.
> It has a very good coverage of the daemon's code and also allows to run the
> daemon through valgrind and verify there are no memory leaks and invalid
> accesses.

Thanks for doing this!

I was on the long vacation and would not have time to look into this in months,
I think. So whenever this lands into Buildroot, I will use it and hence try to
test the thingy.

-- 
With Best Regards,
Andy Shevchenko