Re: [systemd-devel] sdbus errors and their underlaying int value: unique?
On Thu, 4 Mar 2021 10:46:43 -0300 Cristian Rodríguez wrote: > On Tue, Mar 2, 2021 at 7:55 AM Carlo Wood wrote: > > > On Tue, 2 Mar 2021 10:40:25 +0100 > > Carlo Wood wrote: > > > > > I'm not writing my own C++ wrappers around sbus. > > > > I'm now* writing my own C++ wrappers around sbus. > > > > > JUst curious..what is wrong with QTDbus.. ? I strongly suggest you > against the path of reinventing this particular wheel. I started off with sdbus-cpp, and that turned out to be inflexible and not suitable for my application without cloning their repository and making changes. At some point I just got tired of working around issues. One of the main reasons that I decided to completely stop using it is because they use a mutex to make sure only one thread enters the library at a time; which is not how I work (I use mutexes, but don't hold them so long that there is a reasonable risk that they are still locked when another thread tries to lock them; at most a few assembly instructions). But at least as important is that is creation of new threads and/or blocking system calls seemed completely intractable. Sdbus-cpp is doing way more than just wrapping systemd's sdbus and most of it I don't want. I never considered QTDbus because well, I'm not using Qt. I supposed that Qt had the same problems as me: wanting to have sdbus under their own main loop control AND support for C++ - hence being forced to write their own wrapper. But that then (I assumed) would be Qt specific top to bottom; using Qt stuff whenever suitable and a requiring to have a Qt main loop. If I was mistaken at that then that is unfortunate. Regards, Carlo Wood. PS Same story for GDBus. GLib has the tendency to be a COMPLETE solution - using glib stuff everywhere. And I am not using glib (my library is ALSO a complete solution by the way; with -as said before- the emphasis on being scalable to arbitrary many cores and avoiding any and all blocking of threads. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sdbus errors and their underlaying int value: unique?
On Tue, Mar 2, 2021 at 7:55 AM Carlo Wood wrote: > On Tue, 2 Mar 2021 10:40:25 +0100 > Carlo Wood wrote: > > > I'm not writing my own C++ wrappers around sbus. > > I'm now* writing my own C++ wrappers around sbus. > > JUst curious..what is wrong with QTDbus.. ? I strongly suggest you against the path of reinventing this particular wheel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sdbus errors and their underlaying int value: unique?
On Wed, 03 Mar 2021 at 13:51:38 +0100, Lennart Poettering wrote: > On Di, 02.03.21 10:40, Carlo Wood (ca...@alinoe.com) wrote: > > In C++ we have std::error_code which stores both a (unique) domain > > and an int that is defined within that domain. The integer values > > do not have to be globally unique. > > Generally: when doing D-Bus focus on the error names, because that's > the native thing. It seems std::error_code is conceptually the same as the domain and code from GLib's GError (convergent evolution, or inspiration from GLib?), so it would probably be useful to look at how GLib's GDBus maps GError to/from D-Bus errors: https://developer.gnome.org/gio/stable/gio-GDBusError.html In GError, the domain is basically a string (it's a GQuark, which is a handle representing an "interned" string), the code is an int defined within that domain, and there is also a human-readable message. So for instance, org.freedesktop.DBus.Error.NoMemory maps to (domain=G_DBUS_ERROR, code=G_DBUS_ERROR_NO_MEMORY), which behind the scenes is the same as (domain=g_quark_from_string("g-dbus-error-quark"), code=1). smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sdbus errors and their underlaying int value: unique?
On Di, 02.03.21 10:40, Carlo Wood (ca...@alinoe.com) wrote: > Hello, > > thank you for you previous help; I made a lot of progress. > > I'm not writing my own C++ wrappers around sbus. > > I have the following question: > > A sd_bus_error has a name (and a message). The name is usually something > like "org.freedesktop.DBus.Error.InvalidArgs" or > "com.alinoe.DBus.Error.test_error" - in other words it contains a > domain, "org.freedesktop.DBus.Error" and "com.alinoe.DBus.Error" > respectively. > > In C++ we have std::error_code which stores both a (unique) domain > and an int that is defined within that domain. The integer values > do not have to be globally unique. > > For example, org.freedesktop.DBus.Error.InvalidArgs is mapped to > EINVAL which is 22. But can I use 22 too for > com.alinoe.DBus.Error.test_error? This would be fine with > std::error_code; and I'm trying to support conversion from > DBus errors to std::error_code. D-Bus has no concept of error numbers, only of error names (in reverse domain name notation) and human readable messages. Since sd-bus is a C wrapper around D-Bus, and in C it is more common to deal with 'errno' style error codes there's a bit of infrastructure in place to map names to errors, since quite often it is useful to propagate errno-style error codes on where one receives a D-Bus error, and vice versa. sd_bus_error_get_errno() wraps the error name → errno mapping, and sd_bus_error_set_errno() can be used for the opposite direction. Note however, that D-Bus names are a lot more precise, and thus multiple error names might map to the same error numbers. sd-bus has a bunch of mappings built-in, for well-known errors from the D-Bus spec and from systemd. You can define more such mappings via sd_bus_error_add_map(), to make sd-bus translate things with them too. Generally: when doing D-Bus focus on the error names, because that's the native thing. Use the error numbers only really if you really need to provide C-style errnos instead, and ignore them, and never forget that the mapping logic is not a D-Bus invention but an sd-bus one. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sdbus errors and their underlaying int value: unique?
On Tue, 2 Mar 2021 10:40:25 +0100 Carlo Wood wrote: > I'm not writing my own C++ wrappers around sbus. I'm now* writing my own C++ wrappers around sbus. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sdbus errors and their underlaying int value: unique?
Hello, thank you for you previous help; I made a lot of progress. I'm not writing my own C++ wrappers around sbus. I have the following question: A sd_bus_error has a name (and a message). The name is usually something like "org.freedesktop.DBus.Error.InvalidArgs" or "com.alinoe.DBus.Error.test_error" - in other words it contains a domain, "org.freedesktop.DBus.Error" and "com.alinoe.DBus.Error" respectively. In C++ we have std::error_code which stores both a (unique) domain and an int that is defined within that domain. The integer values do not have to be globally unique. For example, org.freedesktop.DBus.Error.InvalidArgs is mapped to EINVAL which is 22. But can I use 22 too for com.alinoe.DBus.Error.test_error? This would be fine with std::error_code; and I'm trying to support conversion from DBus errors to std::error_code. For example, I have a class dbus::Error that simply wraps a sd_bus_error struct. I can do: dbus::Error error = function_returning_an_error(); std::error_code code = error; // Convert sd_bus_error to std::error_code. std::cout << code << " [" << code.message() << "]" << std::endl; (Can also do std::cout << error, of course, but this is for demonstration) which could print something like: com.alinoe.dbus.Error:22 [test_error] or org.freedesktop.DBus.Error:22 [Invalid argument] Adding "com.alinoe.DBus.Error.test_error" to sdbus must be done as follows: enum alinoe_dbus_errors { test_error = 22 // Is this value allowed? }; const sd_bus_error_map alinoe_com_errors[] = { SD_BUS_ERROR_MAP("com.alinoe.dbus.Error.test_error", test_error), SD_BUS_ERROR_MAP_END }; sd_bus_error_add_map(alinoe_com_errors); I don't think I can reasonably know which codes (int values) are already in use: many libraries could add their own errors and I don't know what that is, or what will be added in the future (ie, to sdbus). This is why std::error_code doesn't demand the numeric values to be unique except inside their own domain. Does sdbus require me to use globally unique integer values? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel