libgpiod v2: C++ bindings

This is the bulk of work implementing C++ bindings for the new libgpiod API. The tests are not converted yet but the examples are fully functional. More details in the cover letter as this patch will be squashed with the one for the core C library anyway.

bindings/cxx/chip.cpp +10 -3

-GPIOD_CXX_API bool is_gpiochip_device(const ::std::string& path)
+struct chip::impl
 {
-	return ::gpiod_is_gpiochip_device(path.c_str());
-}
+	impl(const ::std::string& path)
+		: chip(open_chip(path)),
+		  name(::gpiod_chip_get_name(this->chip.get())),
+		  label(::gpiod_chip_get_label(this->chip.get()))
+	{
+
+	}
+
+	impl(const impl& other) = delete;

bindings/cxx/edge-event.cpp new file +9 -0

new file mode 100644
index 0000000..d6dce22
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: LGPL-3.0-or-later
+// SPDX-FileCopyrightText: 2021 Bartosz Golaszewski <[email protected]>
+
+#include <map>
+#include <stdexcept>
+#include <system_error>
+#include <utility>
+
+#include "internal.hpp"

bindings/cxx/edge-event.cpp new file +8 -0

+	/**
+	 * @brief Retrieve the current snapshot of line information for a
+	 *        single line.
+	 * @param offset Offset of the line to get the info for.
+	 * @param watch Indicates whether the caller wants to watch for line
+	 *              info changes.
+	 * @return New ::gpiod::line_info object.
+	 */

bindings/cxx/edge-event.cpp new file +5 -0

+	/**
+	 * @brief Move assignment operator.
+	 * @param other Object to move.
+	 * @return Reference to self.
+	 */

bindings/cxx/edge-event.cpp new file +9 -0

+/**
+ * @brief Contains an immutable snapshot of the line's state at the
+ *        time when the object of this class was instantiated.
+ */
+class line_info
+{
+public:
+
+	/**

bindings/cxx/edge-event.cpp new file +7 -0

+/**
+ * @brief Stores the context of a set of requested GPIO lines.
+ */
+class line_request
+{
+public:
+

Quoted 5 lines · Bartosz Golaszewski

This is the bulk of work implementing C++ bindings for the new libgpiod API. The tests are not converted yet but the examples are fully functional. More details in the cover letter as this patch will be squashed with the one for the core C library anyway.

My apologies for not getting around to reviewing v2, so here is a quick(??) review of v3...

I don't have any problems with the C API changes in patches 1 and 2. I would prefer that we didn't need the num_lines, offsets and capacity getters, but their addition is a reasonable compromise.

<snip>

Quoted 18 lines

bindings/cxx/chip.cpp +14 -3

-GPIOD_CXX_API bool is_gpiochip_device(const ::std::string& path)
+struct chip::impl
 {
-     return ::gpiod_is_gpiochip_device(path.c_str());
-}
+     impl(const ::std::string& path)
+             : chip(open_chip(path)),
+               name(::gpiod_chip_get_name(this->chip.get())),
+               label(::gpiod_chip_get_label(this->chip.get()))
+     {
+
+     }
+
+     impl(const impl& other) = delete;
+     impl(impl&& other) = delete;
+     impl& operator=(const impl& other) = delete;
+     impl& operator=(impl&& other) = delete;
+

bindings/cxx/chip.cpp line 64

Quoted 6 lines

bindings/cxx/chip.cpp +6 -0

+     void throw_if_closed(void) const
+     {
+             if (!this->chip)
+                     throw ::std::logic_error("GPIO chip has been closed");
+     }
+

Perhaps throw something more specific than a logic_error?

<snip>

Quoted 24 lines

bindings/cxx/edge-event.cpp new file +18 -0

new file mode 100644
index 0000000..d6dce22
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: LGPL-3.0-or-later
+// SPDX-FileCopyrightText: 2021 Bartosz Golaszewski <[email protected]>
+
+#include <map>
+#include <stdexcept>
+#include <system_error>
+#include <utility>
+
+#include "internal.hpp"
+
+namespace gpiod {
+
+namespace {
+
+const ::std::map<int, edge_event::type> event_type_mapping = {
+     { GPIOD_LINE_EVENT_RISING_EDGE,         edge_event::type::RISING_EDGE },
+     { GPIOD_LINE_EVENT_FALLING_EDGE,        edge_event::type::FALLING_EDGE }
+};

bindings/cxx/edge-event.cpp line 19

Quoted 1 line

bindings/cxx/edge-event.cpp new file +1 -0

+

Use of a map for just two event types seems like overkill. Wouldn't an if-else in edge_event::get_type(void) be simpler and cleaner? Also, as written, edge_event::get_type(void) can throw std::out_of_range which doesn't seem right. Wouldn't std::range_error be more appropriate? Or adding an unknown event type for failed mappings, so get_type() can never throw??

Same applies for mappings throughout. If the C++ values match the C values then you could just perform a range check and cast for the cases where there are more than two values.

<snip>

Quoted 15 lines

bindings/cxx/edge-event.cpp new file +15 -0

+     /**
+      * @brief Retrieve the current snapshot of line information for a
+      *        single line.
+      * @param offset Offset of the line to get the info for.
+      * @param watch Indicates whether the caller wants to watch for line
+      *              info changes.
+      * @return New ::gpiod::line_info object.
+      */
+     line_info get_line_info(unsigned int offset, bool watch = false) const;
+
+     /**
+      * @brief Wrapper around ::gpiod::chip::get_line_info that retrieves
+      *        the line info and starts watching the line for changes.
+      * @param offset Offset of the line to get the info for.
+      * @return New ::gpiod::line_info object.

bindings/cxx/edge-event.cpp

Quoted 3 lines

bindings/cxx/edge-event.cpp new file +3 -0

+      */
+     line_info watch_line_info(unsigned int offset) const;
+

I repeat my objection to get_line_info() accepting a watch parameter and watch_line_info() wrapping it. While they both happen to return line_info, the purpose of the two methods are quite different and so should be kept separate.

Also, should be watch_line_info() really be allowed on a const chip? While it does not alter the C++ object, and so technically can be allowed on a const, it does alter the state of the underlying C object and so I would argue it should not be allowed.

<snip>

bindings/cxx/edge-event.cpp

Quoted 13 lines

bindings/cxx/edge-event.cpp new file +13 -0

+     /**
+      * @brief Get the constant reference to the edge event at given index.
+      * @param index Index of the event in the buffer.
+      * @return Constant reference to the edge event.
+      */
+     const edge_event& get_event(unsigned int index) const;
+
+     /**
+      * @brief Get the number of edge events currently stored in the buffer.
+      * @return Number of edge events in the buffer.
+      */
+     unsigned int num_events(void) const;
+

A getter not prefixed with "get_" ;-).
(note that I'm kidding - I prefer it this way - more on that later in class line_info)

bindings/cxx/edge-event.cpp

Quoted 6 lines

bindings/cxx/edge-event.cpp new file +6 -0

+     /**
+      * @brief Maximum capacity of the buffer.
+      * @return Buffer capacity.
+      */
+     unsigned int capacity(void) const noexcept;
+

And again.

<snip>

bindings/cxx/edge-event.cpp

Quoted 8 lines

bindings/cxx/edge-event.cpp new file +8 -0

+/**
+ * @brief Contains a set of line config options used in line requests and
+ *        reconfiguration.
+ */
+class line_config
+{
+public:
+

This class has setters but no getters.
There is no use case for getters?
Also applies to C API - just wondering given the addition of the getters in patch 1 and 2 - there may be cases where the user would like to read back the config?

bindings/cxx/edge-event.cpp

Quoted 13 lines

bindings/cxx/edge-event.cpp new file +13 -0

+     /**
+      * @brief Direction settings.
+      */
+     enum class direction : unsigned int
+     {
+             AS_IS = 1,
+             /**< Request the line(s), but don't change current direction. */
+             INPUT,
+             /**< Request the line(s) for reading the GPIO line state. */
+             OUTPUT
+             /**< Request the line(s) for setting the GPIO line state. */
+     };
+

line_info and line_config should use common direction types (also applies to C API)? Perhaps in a ::gpiod::line namespace?

Same applies to other fields that map to GPIO_V2_LINE_FLAGs, so edge, drive, bias and event clock.
Oh, and the C API lacks a gpiod_line_info_get_event_clock(), and not surprisingly class line_info lacks a getter for event clock.

<snip>

Quoted 5 lines

bindings/cxx/edge-event.cpp new file +5 -0

+     /**
+      * @brief Move assignment operator.
+      * @param other Object to move.
+      * @return Reference to self.
+      */

bindings/cxx/edge-event.cpp

Quoted 10 lines

bindings/cxx/edge-event.cpp new file +10 -0

+     line_config& operator=(line_config&& other) noexcept;
+
+     /**
+      * @brief Set the direction, either globally or for a set of offsets.
+      * @param dir_val New direction setting.
+      * @param offsets Vector of line offsets to set the direction for. If
+      *                empty, the setting will be global.
+      */
+     void set_direction(direction dir_val, const line_offsets& offsets = line_offsets()) const;
+

Setters should not be const.
While your implementation may allow it now, conceptually it is wrong. And what happens if your implementation changes later? Removing the const later would break ABI compatibility.

This applies throughout.

<snip>

Quoted 9 lines

bindings/cxx/edge-event.cpp new file +9 -0

+/**
+ * @brief Contains an immutable snapshot of the line's state at the
+ *        time when the object of this class was instantiated.
+ */
+class line_info
+{
+public:
+
+     /**

bindings/cxx/edge-event.cpp

Quoted 10 lines

bindings/cxx/edge-event.cpp new file +10 -0

+      * @brief Direction settings.
+      */
+     enum class direction : unsigned int
+     {
+             INPUT = 1,
+             /**< Direction is input - we're reading the state of a GPIO line. */
+             OUTPUT
+             /**< Direction is output - we're driving the GPIO line. */
+     };
+

And as previously noted, I'd like to see the line_info and line_config use common types.

And I agree with Jack Winch on not prefixing getters with "get_". The only thing I would change from Jack's suggestion is to put the types in the line namespace so rather than his

    using direction_type = ::gpiod::direction;

I would have

    using direction_type = ::gpiod::line::direction;

- if you want to use an alias at all.

The types are used relatively rarely, so I'm no fussed if their names are a bit clunky. OTOH getters are frequently used and I much prefer the shorter form.

Where you have an "enum class type" that would conflict with a type() getter, such as in info_event and edge_event, I would rename the enum to event_type, or similar.

That applies throughout.

Wrt setters, I'm happy with them being prefixed with "set_" so they are clearly distinguished from getters.

<snip>

Quoted 7 lines

bindings/cxx/edge-event.cpp new file +7 -0

+/**
+ * @brief Stores the context of a set of requested GPIO lines.
+ */
+class line_request
+{
+public:
+

<snip>

bindings/cxx/edge-event.cpp

Quoted 7 lines

bindings/cxx/edge-event.cpp new file +7 -0

+
+     /**
+      * @brief Get the number of requested lines.
+      * @return Number of lines in this request.
+      */
+     unsigned int num_lines(void) const;
+

More getters not prefixed with "get_" ;-).

bindings/cxx/edge-event.cpp

Quoted 6 lines

bindings/cxx/edge-event.cpp new file +6 -0

+     /**
+      * @brief Get the list of offsets of requested lines.
+      * @return List of hardware offsets of the lines in this request.
+      */
+     line_offsets offsets(void) const;
+

And again.

<snip>

bindings/cxx/edge-event.cpp

Quoted 7 lines

bindings/cxx/edge-event.cpp new file +7 -0

+template<class enum_type, void global_func(::gpiod_line_config*, int),
+      void subset_func(::gpiod_line_config*, int, unsigned int, const unsigned int*)>
+void set_mapped_value(::gpiod_line_config* config, enum_type value,
+                   const line_offsets& offsets, const ::std::map<enum_type, int>& mapping)
+{
+     int mapped_val = mapping.at(value);
+

This can throw ::std::out_of_range, which set_mapped_value() should catch and re-throw as ::std::invalid_argument.

The use of templating means mapping using ::std::map in this direction makes more sense than the reverse in the other modules, but I'm still not a fan.

<snip>

bindings/cxx/edge-event.cpp

Quoted 6 lines

bindings/cxx/edge-event.cpp new file +6 -0

+void line_request::impl::throw_if_released(void) const
+{
+     if (!this->request)
+             throw ::std::logic_error("GPIO lines have been released");
+}
+

Throw a more specific exception, rather than a generic logic_error.

<snip>

Hopefully I haven't snipped out too much...

Cheers,
Kent.

Quoted 35 lines · Kent Gibson

Quoted 5 lines · Bartosz Golaszewski

This is the bulk of work implementing C++ bindings for the new libgpiod API. The tests are not converted yet but the examples are fully functional. More details in the cover letter as this patch will be squashed with the one for the core C library anyway.

My apologies for not getting around to reviewing v2, so here is a quick(??) review of v3...

I don't have any problems with the C API changes in patches 1 and 2. I would prefer that we didn't need the num_lines, offsets and capacity getters, but their addition is a reasonable compromise.

<snip>

Quoted 18 lines

bindings/cxx/chip.cpp +14 -3

-GPIOD_CXX_API bool is_gpiochip_device(const ::std::string& path)
+struct chip::impl
 {
-     return ::gpiod_is_gpiochip_device(path.c_str());
-}
+     impl(const ::std::string& path)
+             : chip(open_chip(path)),
+               name(::gpiod_chip_get_name(this->chip.get())),
+               label(::gpiod_chip_get_label(this->chip.get()))
+     {
+
+     }
+
+     impl(const impl& other) = delete;
+     impl(impl&& other) = delete;
+     impl& operator=(const impl& other) = delete;
+     impl& operator=(impl&& other) = delete;
+

Quoted 9 lines

bindings/cxx/chip.cpp line 64

Quoted 6 lines

bindings/cxx/chip.cpp +6 -0

+     void throw_if_closed(void) const
+     {
+             if (!this->chip)
+                     throw ::std::logic_error("GPIO chip has been closed");
+     }
+

Perhaps throw something more specific than a logic_error?

There's no standard exception that would inherit from std::logic_error that would fit here. I can define new exceptions (gpiod::chip_closed and gpiod::request_released) inheriting from logic_error if that works for you.

Quoted 26 lines

<snip>

Quoted 24 lines

bindings/cxx/edge-event.cpp new file +18 -0

new file mode 100644
index 0000000..d6dce22
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: LGPL-3.0-or-later
+// SPDX-FileCopyrightText: 2021 Bartosz Golaszewski <[email protected]>
+
+#include <map>
+#include <stdexcept>
+#include <system_error>
+#include <utility>
+
+#include "internal.hpp"
+
+namespace gpiod {
+
+namespace {
+
+const ::std::map<int, edge_event::type> event_type_mapping = {
+     { GPIOD_LINE_EVENT_RISING_EDGE,         edge_event::type::RISING_EDGE },
+     { GPIOD_LINE_EVENT_FALLING_EDGE,        edge_event::type::FALLING_EDGE }
+};

Quoted 9 lines

bindings/cxx/edge-event.cpp line 19

Quoted 1 line

bindings/cxx/edge-event.cpp new file +1 -0

+

Use of a map for just two event types seems like overkill. Wouldn't an if-else in edge_event::get_type(void) be simpler and cleaner? Also, as written, edge_event::get_type(void) can throw std::out_of_range which doesn't seem right. Wouldn't std::range_error be more appropriate? Or adding an unknown event type for failed mappings, so get_type() can never throw??

While it's true that we can throw the range_error, it's very unlikely and would occur only if a serious programming error was present in the C library or the kernel.

I'm fine with this possibility - adding an
unknown type, would suggest this is a normal situation and not an exception.

For the mapping: to me this looks more consistent and also allows to detect the rare and unlikely error mentioned above. In any case - this is an implementation detail and can be changed later.

Quoted 4 lines

Same applies for mappings throughout. If the C++ values match the C values then you could just perform a range check and cast for the cases where there are more than two values.

Casting in general is to be avoided in C++ - as defined in the document Jack linked recently. Mapping isn't expensive and looks more robust IMO. I would prefer to leave it like this.

Quoted 17 lines

<snip>

Quoted 15 lines

bindings/cxx/edge-event.cpp new file +15 -0

+     /**
+      * @brief Retrieve the current snapshot of line information for a
+      *        single line.
+      * @param offset Offset of the line to get the info for.
+      * @param watch Indicates whether the caller wants to watch for line
+      *              info changes.
+      * @return New ::gpiod::line_info object.
+      */
+     line_info get_line_info(unsigned int offset, bool watch = false) const;
+
+     /**
+      * @brief Wrapper around ::gpiod::chip::get_line_info that retrieves
+      *        the line info and starts watching the line for changes.
+      * @param offset Offset of the line to get the info for.
+      * @return New ::gpiod::line_info object.

Quoted 9 lines

bindings/cxx/edge-event.cpp

Quoted 3 lines

bindings/cxx/edge-event.cpp new file +3 -0

+      */
+     line_info watch_line_info(unsigned int offset) const;
+

I repeat my objection to get_line_info() accepting a watch parameter and watch_line_info() wrapping it. While they both happen to return line_info, the purpose of the two methods are quite different and so should be kept separate.

OK, I will change it.

Quoted 5 lines

Also, should be watch_line_info() really be allowed on a const chip? While it does not alter the C++ object, and so technically can be allowed on a const, it does alter the state of the underlying C object and so I would argue it should not be allowed.

Makes sense.

Quoted 31 lines

<snip>

bindings/cxx/edge-event.cpp

Quoted 13 lines

bindings/cxx/edge-event.cpp new file +13 -0

+     /**
+      * @brief Get the constant reference to the edge event at given index.
+      * @param index Index of the event in the buffer.
+      * @return Constant reference to the edge event.
+      */
+     const edge_event& get_event(unsigned int index) const;
+
+     /**
+      * @brief Get the number of edge events currently stored in the buffer.
+      * @return Number of edge events in the buffer.
+      */
+     unsigned int num_events(void) const;
+

A getter not prefixed with "get_" ;-).
(note that I'm kidding - I prefer it this way - more on that later in class line_info)

bindings/cxx/edge-event.cpp

Quoted 6 lines

bindings/cxx/edge-event.cpp new file +6 -0

+     /**
+      * @brief Maximum capacity of the buffer.
+      * @return Buffer capacity.
+      */
+     unsigned int capacity(void) const noexcept;
+

And again.

<snip>

Quoted 15 lines

bindings/cxx/edge-event.cpp

Quoted 8 lines

bindings/cxx/edge-event.cpp new file +8 -0

+/**
+ * @brief Contains a set of line config options used in line requests and
+ *        reconfiguration.
+ */
+class line_config
+{
+public:
+

This class has setters but no getters.
There is no use case for getters?
Also applies to C API - just wondering given the addition of the getters in patch 1 and 2 - there may be cases where the user would like to read back the config?

IMO if a use-case like this appears, we can extend the interface. The reason for adding the new functions was because we added the all-lines getters and now the user would need to store the offsets outside the request if we didn't provide them. Adding getters for config structures now would unnecessarily bloat the interface. Let me know if you disagree though. I usually eventually get convinced by you. :)

Quoted 14 lines

Quoted 13 lines

bindings/cxx/edge-event.cpp new file +13 -0

+     /**
+      * @brief Direction settings.
+      */
+     enum class direction : unsigned int
+     {
+             AS_IS = 1,
+             /**< Request the line(s), but don't change current direction. */
+             INPUT,
+             /**< Request the line(s) for reading the GPIO line state. */
+             OUTPUT
+             /**< Request the line(s) for setting the GPIO line state. */
+     };
+

Quoted 3 lines

line_info and line_config should use common direction types (also applies to C API)? Perhaps in a ::gpiod::line namespace?

So that would seem obvious to do this but the values stored in line info and passed to line config are not always the same. BIAS_UNKNOWN and BIAS_AS_IS are not the same and the former is only suitable for line_info while the latter only works for the config.

I agree though
that it may be a bit confusing for users. If we'd change it - where should these go wrt doxygen sections of the core API?

This series contains the implementation of the C++ bindings for libgpiod v2. In general the C++ library follows the data structure model as defined by the C library with one notable exception: objects that represent immutable snapshots of kernel data (line_info and edge & info events) are copyable (or rather shared behind the scenes using ::std::shared_ptr). The rest of the classes delete their copy constructors and assignment operators and are only move constructible and move assignable.

All classes follow the pimpl idiom - using either shared_ptr or unique_ptr - and all implementations are hidden from the user for easier maintenance and less ABI breakage in the future.

The edge_event class is a bit of a special case. While it looks the same as other copyable objects to the user, the implementation uses a tiny bit of polymorphism (although it never crosses the ABI boundary). This is done to make it possible to use the edge_event_buffer without any memory allocations like what the C API enables. The edge_event objects stored in the buffer only contain a raw pointer to the C object stored in the underlying C edge_event_buffer. The event is copied into a fully managed object once the copy assignment operator is called.

I'm Cc'ing people who showed interest and helped me with C++ bindings before for review.

v1 -> v2:
Kent: I addressed most points from your review. Some are unaddressed due to personal preference (for instance: I still allow creating of empty line-request objects as they may be reused in subsequent requests). I also kept the 'watch' argument in get_line_info() as well as the boolean operators for chip and request - although with (hopefully) better documentation.

v2 -> v3:
- use scoped class enums instead of regular integer ones
- rename getters to get_<property>() in order to avoid name conflicts with the new enum types

The first two patches extend the core C API of libgpiod as discussed.

Bartosz Golaszewski (3):
API: add a function for retrieving the capacity of edge event buffers
API: extend the line request functionality
bindings: cxx: implement C++ bindings for libgpiod v2.0

 Doxyfile.in                                 |   4 +-
 bindings/cxx/Makefile.am                    |  16 +-
 bindings/cxx/chip.cpp                       | 214 +++--
 bindings/cxx/edge-event-buffer.cpp          | 103 +++
 bindings/cxx/edge-event.cpp                 | 123 +++
 bindings/cxx/examples/Makefile.am           |  12 +-
 bindings/cxx/examples/gpiodetectcxx.cpp     |   9 +-
 bindings/cxx/examples/gpiofindcxx.cpp       |   2 +-
 bindings/cxx/examples/gpiogetcxx.cpp        |  12 +-
 bindings/cxx/examples/gpioinfocxx.cpp       |  63 +-
 bindings/cxx/examples/gpiomoncxx.cpp        |  39 +-
 bindings/cxx/examples/gpiosetcxx.cpp        |  19 +-
 bindings/cxx/gpiod.hpp                      | 938 +-------------------
 bindings/cxx/gpiodcxx/Makefile.am           |  14 +
 bindings/cxx/gpiodcxx/chip.hpp              | 180 ++++
 bindings/cxx/gpiodcxx/edge-event-buffer.hpp | 115 +++
 bindings/cxx/gpiodcxx/edge-event.hpp        | 125 +++
 bindings/cxx/gpiodcxx/info-event.hpp        | 108 +++
 bindings/cxx/gpiodcxx/line-config.hpp       | 250 ++++++
 bindings/cxx/gpiodcxx/line-info.hpp         | 209 +++++
 bindings/cxx/gpiodcxx/line-request.hpp      | 207 +++++
 bindings/cxx/gpiodcxx/misc.hpp              |  49 +
 bindings/cxx/gpiodcxx/request-config.hpp    |  97 ++
 bindings/cxx/info-event.cpp                 |  89 ++
 bindings/cxx/internal.hpp                   | 168 +++-
 bindings/cxx/iter.cpp                       |  60 --
 bindings/cxx/line-config.cpp                | 226 +++++
 bindings/cxx/line-info.cpp                  | 150 ++++
 bindings/cxx/line-request.cpp               | 194 ++++
 bindings/cxx/line.cpp                       | 321 -------
 bindings/cxx/line_bulk.cpp                  | 366 --------
 bindings/cxx/misc.cpp                       |  18 +
 bindings/cxx/request-config.cpp             |  80 ++
 configure.ac                                |   1 +
 include/gpiod.h                             |  63 +-
 lib/edge-event.c                            |   6 +
 lib/line-request.c                          |  50 +-
 tools/gpioget.c                             |   3 +-
 38 files changed, 2854 insertions(+), 1849 deletions(-)
 create mode 100644 bindings/cxx/edge-event-buffer.cpp
 create mode 100644 bindings/cxx/edge-event.cpp
 create mode 100644 bindings/cxx/gpiodcxx/Makefile.am
 create mode 100644 bindings/cxx/gpiodcxx/chip.hpp
 create mode 100644 bindings/cxx/gpiodcxx/edge-event-buffer.hpp
 create mode 100644 bindings/cxx/gpiodcxx/edge-event.hpp
 create mode 100644 bindings/cxx/gpiodcxx/info-event.hpp
 create mode 100644 bindings/cxx/gpiodcxx/line-config.hpp
 create mode 100644 bindings/cxx/gpiodcxx/line-info.hpp
 create mode 100644 bindings/cxx/gpiodcxx/line-request.hpp
 create mode 100644 bindings/cxx/gpiodcxx/misc.hpp
 create mode 100644 bindings/cxx/gpiodcxx/request-config.hpp
 create mode 100644 bindings/cxx/info-event.cpp
 delete mode 100644 bindings/cxx/iter.cpp
 create mode 100644 bindings/cxx/line-config.cpp
 create mode 100644 bindings/cxx/line-info.cpp
 create mode 100644 bindings/cxx/line-request.cpp
 delete mode 100644 bindings/cxx/line.cpp
 delete mode 100644 bindings/cxx/line_bulk.cpp
 create mode 100644 bindings/cxx/misc.cpp
 create mode 100644 bindings/cxx/request-config.cpp

--
2.30.1

Hello Bartosz,

I am most certainly being *dense* here, but which libgpiod branch should I be applying this patch series to? Also, what other patch series is this particular set of patches dependent on? I tried to apply against master and next/libgpiod-2.0 without much success this weekend. Also, just for clarity, how is the next/libgpiod-2.0 branch being used at current? Which and at what point are you applying patches to this particular branch?

Once I've got over this basic hurdle, I'd like to do a 'holistic' review of this patch series. As I've not been following changes to either the kernel subsystem or user library as of late, I feel this approach to be more appropriate and thorough.

Finally, what is the target deadline for completion of the v2 API?

It's actually my fault. Let me explain: the development of the v2 API for the entire project (C, C++ and Python parts) happens in the next/libgpiod-2.0 branch of
git://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git I squash the new changes into the big patch with the plan of resending it for a final review once we agree on the interface (more or less anyway). That will allow the repo to remain bisectable. Then we'll be able to fine-tune different elements.

Maybe you could wait until I post v4? I'm addressing a lot of issues in this revision. Previous small patches have already been squashed and they concerned the core C library anyway.

There's no target, it'll be ready when it's done.

PS How did the move go?