This commit introduces a common storage backend for SUIT manifest
payloads. Different backends can be compiled into a single firmware.
Degending on the component name in the SUIT manifest, a storage backend
is selected by the parser.
For an app, a user usually uses `gnrc_ipv6_router_default` to activate
routing behavior. `gnrc_sixlowpan_router_default` is used by that to
pull in further dependencies for 6LoWPAN routers. It shouldn't pull in
`gnrc_ipv6_router_default` again, as this introduces a cyclic
dependency.
It has no real purpose other than pulling in `gnrc_ipv6_router` as a
dependency, which is already done in other places (or by pulling in its
dependencies).
Just because a user pulls in the DNS client (`sock_dns`) doesn't mean
they want to pull in RDNSS option support as well. Besides, since
`gnrc_ipv6_nib_dns` depends on `gnrc_ipv6_nib`, this forms a circular
dependency that really isn't necessary.
Support for picolibc as alternative libc implementation is added with
this commit. For now only cortex-m CPU's are supported.
Enable via PICOLIBC=1
---
v2:
squash fixes in
v3:
Remove picolibc integer printf/scanf stuff from sys/Makefile.include,
it gets set in makefiles/libc/picolibc.mk
fixup for dependency
It is desireable to have a way to identify network devices.
This should be independent from the type of netdev, so a common identifier is needed.
Base this on the driver ID and the index in the configuration struct.
This way we achive unique IDs that stay consistent for any firmware flashed on a board.
- Add libstdcpp feature to indicate a platform is providing a libstdc++
implementation ready for use
- The existing cpp feature now only indicates a working C++ toolchain without
libstdc++. (E.g. still useful for the Arduino compatibility layer.)
- Added libstdcpp as required feature were needed
- Added some documentation on C++ on RIOT
Instead of making a NETTYPE definition dependent on an implementation
module, this change makes it dependent on a pseudo-module for each
specific NETTYPE and makes the respective implementation modules
dependent on it.
This has two advantages:
- one does not need include the whole implementation module to
subscribe to a NETTYPE for testing or to provide an alternative
implementation
- A lot of circular dependencies related to GNRC could be untangled.
E.g. the only reason `gnrc_icmpv6` needs the `gnrc_ipv6` is because it
uses `GNRC_NETTYPE_IPV6` to search for the IPv6 header in an ICMPv6
when demultiplexing an ICMPv6 header.
This change does not resolve these dependencies or include usages where
needed. The only dependency change is the addition of the
pseudo-modules to the implementation modules.
