[PATCH] libubus: Make UBUS_* macros work cleanly in C++

2024-08-13 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Note: I’ve also submitted this patch as a GitHub PR 
(https://github.com/openwrt/ubus/pull/3) but I’m not sure anyone actually looks 
there for contributions, so I’m submitting it as a patch here as well.

-- >8 --
C++ is picky about initializer order, and (depending on flags) missing fields.
This fix makes UBUS_METHOD_* and UBUS_OBJECT_TYPE initialize all fields of the
respective structs in the correct order, making those macros usable from C++.

Also replace BIT(x) with an explicit expression since BIT() may not be defined.

Signed-off-by: Karsten Sperling 
---
CMakeLists.txt   |  9 +
libubus.h| 41 +---
tests/CMakeLists.txt | 11 +++
tests/test-cplusplus.cpp | 34 +
4 files changed, 72 insertions(+), 23 deletions(-)
create mode 100644 tests/test-cplusplus.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8ae853b..03c3012 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,12 +2,13 @@ cmake_minimum_required(VERSION 3.13)

PROJECT(ubus C)

-ADD_DEFINITIONS(-Wall -Werror)
+ADD_COMPILE_OPTIONS(-Wall -Werror)
IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
-   ADD_DEFINITIONS(-Wextra -Werror=implicit-function-declaration)
-   ADD_DEFINITIONS(-Wformat -Werror=format-security 
-Werror=format-nonliteral)
+  ADD_COMPILE_OPTIONS(-Wextra -Wformat -Werror=format-security 
-Werror=format-nonliteral)
+  
ADD_COMPILE_OPTIONS($<$:-Werror=implicit-function-declaration>)
ENDIF()
-ADD_DEFINITIONS(-Os -std=gnu99 -g3 -Wmissing-declarations 
-Wno-unused-parameter)
+ADD_COMPILE_OPTIONS(-Os -g3 -Wmissing-declarations -Wno-unused-parameter)
+ADD_COMPILE_OPTIONS($<$:-std=gnu99>)

OPTION(BUILD_LUA "build Lua plugin" ON)
OPTION(BUILD_EXAMPLES "build examples" ON)
diff --git a/libubus.h b/libubus.h
index b74a823..fcf62c8 100644
--- a/libubus.h
+++ b/libubus.h
@@ -69,41 +69,44 @@ typedef bool (*ubus_new_object_handler_t)(struct 
ubus_context *ctx, struct ubus_
{   \
.name = _name,  \
.id = 0,\
-   .n_methods = ARRAY_SIZE(_methods),  \
-   .methods = _methods \
+   .methods = _methods,\
+   .n_methods = ARRAY_SIZE(_methods)   \
}

-#define __UBUS_METHOD_NOARG(_name, _handler, _tags)\
-   .name = _name,  \
-   .handler = _handler,\
+#define __UBUS_METHOD_BASE(_name, _handler, _mask, _tags)  \
+   .name = _name,  \
+   .handler = _handler,\
+   .mask = _mask,  \
.tags = _tags

-#define __UBUS_METHOD(_name, _handler, _policy, _tags) \
-   __UBUS_METHOD_NOARG(_name, _handler, _tags),\
-   .policy = _policy,  \
+#define __UBUS_METHOD_NOARG(_name, _handler, _mask, _tags) \
+   __UBUS_METHOD_BASE(_name, _handler, _mask, _tags),  \
+   .policy = NULL, \
+   .n_policy = 0
+
+#define __UBUS_METHOD(_name, _handler, _mask, _policy, _tags)  \
+   __UBUS_METHOD_BASE(_name, _handler, _mask, _tags),  \
+   .policy = _policy,  \
.n_policy = ARRAY_SIZE(_policy)

#define UBUS_METHOD(_name, _handler, _policy)   \
-   { __UBUS_METHOD(_name, _handler, _policy, 0) }
+   { __UBUS_METHOD(_name, _handler, 0, _policy, 0) }

#define UBUS_METHOD_TAG(_name, _handler, _policy, _tags)\
-   { __UBUS_METHOD(_name, _handler, _policy, _tags) }
+   { __UBUS_METHOD(_name, _handler, 0, _policy, _tags) }

#define UBUS_METHOD_MASK(_name, _handler, _policy, _mask) \
-   {   \
-   __UBUS_METHOD(_name, _handler, _policy, 0),\
-   .mask = _mask   \
-   }
+   { __UBUS_METHOD(_name, _handler, _mask, _policy, 0) }

#define UBUS_METHOD_NOARG(_name, _handler)  \
-   { __UBUS_METHOD_NOARG(_name, _handler, 0) }
+   { __UBUS_METHOD_NOARG(_name, _handler, 0, 0) }

#define UBUS_METHOD_TAG_NOARG(_name, _handler, _tags)   \
-   { __UBUS_METHOD_NOARG(_name, _handler, _tags) }
+   { __UBUS_METHOD_NOARG(_name, _handler, 0, _tags) }

-#define UBUS_TAG_STATUSBIT(0)
-#define UBUS_TAG_ADMIN BIT(1)
-#define UBUS_TAG_PRIVATE   BIT(2)
+#define UBUS_TAG_STATUS(1ul << 0)
+#define UBUS_TAG_ADMIN (1ul << 1)
+#define

[PATCH] libubus: Make UBUS_* macros work cleanly in C++

2024-08-13 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Note: I’ve also submitted this patch as a GitHub PR 
(https://github.com/openwrt/ubus/pull/3) but I’m not sure anyone actually looks 
there for contributions, so I’m submitting it as a patch here as well.

-- >8 --
C++ is picky about initializer order, and (depending on flags) missing fields.
This fix makes UBUS_METHOD_* and UBUS_OBJECT_TYPE initialize all fields of the
respective structs in the correct order, making those macros usable from C++.

Also replace BIT(x) with an explicit expression since BIT() may not be defined.

Signed-off-by: Karsten Sperling 
---
CMakeLists.txt   |  9 +
libubus.h| 41 +---
tests/CMakeLists.txt | 11 +++
tests/test-cplusplus.cpp | 34 +
4 files changed, 72 insertions(+), 23 deletions(-)
create mode 100644 tests/test-cplusplus.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8ae853b..03c3012 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,12 +2,13 @@ cmake_minimum_required(VERSION 3.13)

PROJECT(ubus C)

-ADD_DEFINITIONS(-Wall -Werror)
+ADD_COMPILE_OPTIONS(-Wall -Werror)
IF(CMAKE_C_COMPILER_VERSION VERSION_GREATER 6)
-   ADD_DEFINITIONS(-Wextra -Werror=implicit-function-declaration)
-   ADD_DEFINITIONS(-Wformat -Werror=format-security 
-Werror=format-nonliteral)
+  ADD_COMPILE_OPTIONS(-Wextra -Wformat -Werror=format-security 
-Werror=format-nonliteral)
+  
ADD_COMPILE_OPTIONS($<$:-Werror=implicit-function-declaration>)
ENDIF()
-ADD_DEFINITIONS(-Os -std=gnu99 -g3 -Wmissing-declarations 
-Wno-unused-parameter)
+ADD_COMPILE_OPTIONS(-Os -g3 -Wmissing-declarations -Wno-unused-parameter)
+ADD_COMPILE_OPTIONS($<$:-std=gnu99>)

OPTION(BUILD_LUA "build Lua plugin" ON)
OPTION(BUILD_EXAMPLES "build examples" ON)
diff --git a/libubus.h b/libubus.h
index b74a823..fcf62c8 100644
--- a/libubus.h
+++ b/libubus.h
@@ -69,41 +69,44 @@ typedef bool (*ubus_new_object_handler_t)(struct 
ubus_context *ctx, struct ubus_
{   \
.name = _name,  \
.id = 0,\
-   .n_methods = ARRAY_SIZE(_methods),  \
-   .methods = _methods \
+   .methods = _methods,\
+   .n_methods = ARRAY_SIZE(_methods)   \
}

-#define __UBUS_METHOD_NOARG(_name, _handler, _tags)\
-   .name = _name,  \
-   .handler = _handler,\
+#define __UBUS_METHOD_BASE(_name, _handler, _mask, _tags)  \
+   .name = _name,  \
+   .handler = _handler,\
+   .mask = _mask,  \
.tags = _tags

-#define __UBUS_METHOD(_name, _handler, _policy, _tags) \
-   __UBUS_METHOD_NOARG(_name, _handler, _tags),\
-   .policy = _policy,  \
+#define __UBUS_METHOD_NOARG(_name, _handler, _mask, _tags) \
+   __UBUS_METHOD_BASE(_name, _handler, _mask, _tags),  \
+   .policy = NULL, \
+   .n_policy = 0
+
+#define __UBUS_METHOD(_name, _handler, _mask, _policy, _tags)  \
+   __UBUS_METHOD_BASE(_name, _handler, _mask, _tags),  \
+   .policy = _policy,  \
.n_policy = ARRAY_SIZE(_policy)

#define UBUS_METHOD(_name, _handler, _policy)   \
-   { __UBUS_METHOD(_name, _handler, _policy, 0) }
+   { __UBUS_METHOD(_name, _handler, 0, _policy, 0) }

#define UBUS_METHOD_TAG(_name, _handler, _policy, _tags)\
-   { __UBUS_METHOD(_name, _handler, _policy, _tags) }
+   { __UBUS_METHOD(_name, _handler, 0, _policy, _tags) }

#define UBUS_METHOD_MASK(_name, _handler, _policy, _mask) \
-   {   \
-   __UBUS_METHOD(_name, _handler, _policy, 0),\
-   .mask = _mask   \
-   }
+   { __UBUS_METHOD(_name, _handler, _mask, _policy, 0) }

#define UBUS_METHOD_NOARG(_name, _handler)  \
-   { __UBUS_METHOD_NOARG(_name, _handler, 0) }
+   { __UBUS_METHOD_NOARG(_name, _handler, 0, 0) }

#define UBUS_METHOD_TAG_NOARG(_name, _handler, _tags)   \
-   { __UBUS_METHOD_NOARG(_name, _handler, _tags) }
+   { __UBUS_METHOD_NOARG(_name, _handler, 0, _tags) }

-#define UBUS_TAG_STATUSBIT(0)
-#define UBUS_TAG_ADMIN BIT(1)
-#define UBUS_TAG_PRIVATE   BIT(2)
+#define UBUS_TAG_STATUS(1ul << 0)
+#define UBUS_TAG_ADMIN (1ul << 1)
+#define

[PATCH] build: propagate errors in scan and feed update

2023-08-28 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Currently, when an error occurs during scanning of a package Makefile, an
error message is logged, but the error is not actually propagated. This
makes it easy for build scripts to accidentally proceed based on an incomplete
package scan.

Propagate errors correctly in scan.mk and update_index in the feeds script.

Signed-off-by: Karsten Sperling 
---
 include/scan.mk |  1 +
 scripts/feeds   | 10 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/scan.mk b/include/scan.mk
index 33a5832ff5..fa1909caa3 100644
--- a/include/scan.mk
+++ b/include/scan.mk
@@ -55,6 +55,7 @@ define PackageDir
$(NO_TRACE_MAKE) --no-print-dir -r DUMP=1 FEED="$(call 
feedname,$(2))" -C $(SCAN_DIR)/$(2) $(SCAN_MAKEOPTS) > 
$(TOPDIR)/logs/$(SCAN_DIR)/$(2)/dump.txt 2>&1; \
$$(call progress,ERROR: please fix 
$(SCAN_DIR)/$(2)/Makefile - see logs/$(SCAN_DIR)/$(2)/dump.txt for details\n) \
rm -f $$@; \
+   exit 2; \
}; \
echo; \
} > $$@.tmp
diff --git a/scripts/feeds b/scripts/feeds
index aee73e793f..f321649807 100755
--- a/scripts/feeds
+++ b/scripts/feeds
@@ -127,11 +127,11 @@ sub update_index($)
-d "./feeds/$name.tmp" or mkdir "./feeds/$name.tmp" or return 1;
-d "./feeds/$name.tmp/info" or mkdir "./feeds/$name.tmp/info" or return 
1;
 
-   system("$mk -s prepare-mk OPENWRT_BUILD= 
TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"");
-   system("$mk -s -f include/scan.mk IS_TTY=1 SCAN_TARGET=\"packageinfo\" 
SCAN_DIR=\"feeds/$name\" SCAN_NAME=\"package\" SCAN_DEPTH=5 SCAN_EXTRA=\"\" 
TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"");
-   system("$mk -s -f include/scan.mk IS_TTY=1 SCAN_TARGET=\"targetinfo\" 
SCAN_DIR=\"feeds/$name\" SCAN_NAME=\"target\" SCAN_DEPTH=5 SCAN_EXTRA=\"\" 
SCAN_MAKEOPTS=\"TARGET_BUILD=1\" TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"");
-   system("ln -sf $name.tmp/.packageinfo ./feeds/$name.index");
-   system("ln -sf $name.tmp/.targetinfo ./feeds/$name.targetindex");
+   system("$mk -s prepare-mk OPENWRT_BUILD= 
TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"") == 0 or return 1;
+   system("$mk -s -f include/scan.mk IS_TTY=1 SCAN_TARGET=\"packageinfo\" 
SCAN_DIR=\"feeds/$name\" SCAN_NAME=\"package\" SCAN_DEPTH=5 SCAN_EXTRA=\"\" 
TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"") == 0 or return 1;
+   system("$mk -s -f include/scan.mk IS_TTY=1 SCAN_TARGET=\"targetinfo\" 
SCAN_DIR=\"feeds/$name\" SCAN_NAME=\"target\" SCAN_DEPTH=5 SCAN_EXTRA=\"\" 
SCAN_MAKEOPTS=\"TARGET_BUILD=1\" TMP_DIR=\"$ENV{TOPDIR}/feeds/$name.tmp\"") == 
0 or return 1;
+   system("ln -sf $name.tmp/.packageinfo ./feeds/$name.index") == 0 or 
return 1;
+   system("ln -sf $name.tmp/.targetinfo ./feeds/$name.targetindex") == 0 
or return 1;
 
return 0;
 }
-- 
2.40.1


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Matter integration

2023-07-30 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Lukas,

Exciting to see Matter being picked up and getting contributions in the open 
source space like this :-)

In terms of the build, I’ve did a bit of work on the Matter SDK side to add a 
“configure” script that aims to provide a somewhat cleaner interface to an 
external build system like OpenWrt than the raw GN / pigweed build provides. 
Feel free to reach out on the Matter SDK repo if you’re running into issues 
with it.

Thanks, Karsten

> On 30/07/2023, at 1:35 AM, Lukas Zeller  wrote:
> 
> Hi Karsten,
> 
> I am very excited to see matter activity in the openwrt space!
> 
> For the past year, I was working on a bridge app for my OpenWrt based 
> SmartHome daemon p44mbrd [1]. To make it work, I already constributed a few 
> things to matter itself, in particular the possibiity to make it use libev 
> [2] for the matter mainloop, and fixing the avahi implementation [3].
> 
> Back then I also hacked some openwrt platform compilation into matter [4] to 
> build the daemon with gn externally, as I failed doing so from within the 
> openwrt buildroot. That does not seem to be necessary any more - I am very 
> glad to see the devel/gn package, and will try to build p44mbrd this way and 
> then create an openwrt package for it.
> 
> My work in and around Openwrt focuses on using the platform for IoT and 
> SmartHome, and using the matter SDK as a bridge with dynamic endpoints (new 
> PR for that see [6]), not as a router/ap. So I probably cannot help much in 
> the latter field, but still hope I might be able to contribute from general 
> openwrt / matter experience.
> 
> Looking forward to see how this moves forward :-)
> 
> Lukas
> 
> [1] https://github.com/plan44/p44mbrd
> [2] https://github.com/project-chip/connectedhomeip/pull/24232
> [3] https://github.com/project-chip/connectedhomeip/pull/26397
> [4] 
> https://github.com/plan44/connectedhomeip/commit/aabd0ee91bc6dc2906ccf5b73103a538a6dac205
> [5] https://github.com/plan44/plan44-feed/tree/main
> [6] https://github.com/project-chip/connectedhomeip/pull/28372
> 
> 
> 
>> On 27 Jul 2023, at 23:11, Karsten Sperling via openwrt-devel 
>>  wrote:
>> 
>> The sender domain has a DMARC Reject/Quarantine policy which disallows
>> sending mailing list messages using the original "From" header.
>> 
>> To mitigate this problem, the original message has been wrapped
>> automatically by the mailing list software.
>> From: Karsten Sperling 
>> Subject: Matter integration
>> Date: 27 July 2023 at 23:11:10 CEST
>> To: openwrt-devel@lists.openwrt.org
>> 
>> 
>> Hello,
>> 
>> I’m part of an effort by the Connectivity Standards Alliance to bring 
>> support for routers and access points into Matter.  Matter is an open-source 
>> connectivity standard built to enable developers and device manufacturers to 
>> build reliable and secure connected home devices [1][2].
>> 
>> In this context we’re working on a reference implementation for 
>> Matter-enabled routers / access points, which will be taking the form of an 
>> OpenWRT feed.  Development on this has recently started at 
>> https://github.com/project-chip/matter-openwrt.  We’re using OpenWRT as a 
>> platform because of its open nature and great hardware support.  I wanted to 
>> reach out to make the OpenWRT developer community aware of this effort, and 
>> to invite you to collaborate with us if you’re interested.
>> 
>> On a more concrete level, I would also like to ask for support for this 
>> small PR on OpenWRT I’ve opened here: 
>> https://github.com/openwrt/openwrt/pull/13000
>> 
>> The cross-platform nature of the Matter SDK combined with the fact that it 
>> uses git sub-modules for dependency management results in the repo having a 
>> LOT of sub-modules (about 70 direct, 130 total), only 4 of which are needed 
>> when building within OpenWRT. Getting this PR merged would help us to get 
>> the Matter SDK and related software to build cleanly under OpenWRT.
>> 
>> Thanks!
>> 
>> [1] https://buildwithmatter.com <https://buildwithmatter.com/>
>> [2] https://github.com/project-chip/connectedhomeip
>> 
>> 
>> 
>> 
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Matter integration

2023-07-30 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Stijn,

Great to hear that integrating the OpnThread BR is already being worked on, 
that’s definitely going to be of interest to us as well!

Thanks, Karsten

> On 28/07/2023, at 10:33 PM, Stijn Tintel  wrote:
> 
> On 28/07/2023 00:11, Karsten Sperling via openwrt-devel wrote:
>> Hello,
> Hi!
>> 
>> I’m part of an effort by the Connectivity Standards Alliance to bring 
>> support for routers and access points into Matter.  Matter is an open-source 
>> connectivity standard built to enable developers and device manufacturers to 
>> build reliable and secure connected home devices [1][2].
>> 
>> In this context we’re working on a reference implementation for 
>> Matter-enabled routers / access points, which will be taking the form of an 
>> OpenWRT feed.  Development on this has recently started 
>> athttps://github.com/project-chip/matter-openwrt.  We’re using OpenWRT as a 
>> platform because of its open nature and great hardware support.  I wanted to 
>> reach out to make the OpenWRT developer community aware of this effort, and 
>> to invite you to collaborate with us if you’re interested.
> Thanks for letting us know. I, for one, am very interested in Matter (and 
> Thread). I will try the matter-openwrt feed soon. Maybe this can help me 
> finish the PR to add the OpenThread Border Router to OpenWrt [1].
>> 
>> On a more concrete level, I would also like to ask for support for this 
>> small PR on OpenWRT I’ve opened 
>> here:https://github.com/openwrt/openwrt/pull/13000
>> 
>> The cross-platform nature of the Matter SDK combined with the fact that it 
>> uses git sub-modules for dependency management results in the repo having a 
>> LOT of sub-modules (about 70 direct, 130 total), only 4 of which are needed 
>> when building within OpenWRT. Getting this PR merged would help us to get 
>> the Matter SDK and related software to build cleanly under OpenWRT.
>> 
>> Thanks!
>> 
>> [1]https://buildwithmatter.com  <https://buildwithmatter.com/>
>> [2]https://github.com/project-chip/connectedhomeip
>> 
> Stijn
> 
> [1] https://github.com/openwrt/packages/pull/19218
> 
> 


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Matter integration

2023-07-27 Thread Karsten Sperling via openwrt-devel 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

I’m part of an effort by the Connectivity Standards Alliance to bring support 
for routers and access points into Matter.  Matter is an open-source 
connectivity standard built to enable developers and device manufacturers to 
build reliable and secure connected home devices [1][2].

In this context we’re working on a reference implementation for Matter-enabled 
routers / access points, which will be taking the form of an OpenWRT feed.  
Development on this has recently started at 
https://github.com/project-chip/matter-openwrt.  We’re using OpenWRT as a 
platform because of its open nature and great hardware support.  I wanted to 
reach out to make the OpenWRT developer community aware of this effort, and to 
invite you to collaborate with us if you’re interested.

On a more concrete level, I would also like to ask for support for this small 
PR on OpenWRT I’ve opened here: https://github.com/openwrt/openwrt/pull/13000

The cross-platform nature of the Matter SDK combined with the fact that it uses 
git sub-modules for dependency management results in the repo having a LOT of 
sub-modules (about 70 direct, 130 total), only 4 of which are needed when 
building within OpenWRT. Getting this PR merged would help us to get the Matter 
SDK and related software to build cleanly under OpenWRT.

Thanks!

[1] https://buildwithmatter.com 
[2] https://github.com/project-chip/connectedhomeip


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel