This commit introduces the ability to set and manage log levels on a
per-instance basis when dynamic logging is enabled, while maintaining
backward compatibility with existing logging behaviors.
The existing `otLoggingGetLevel()` and `otLoggingSetLevel()` APIs are
repurposed to manage the "global" log level. They continue to behave
exactly as before in both single-instance and multi-instance
configurations, ensuring that existing users of these APIs do not need
to change their implementations. To provide more granular control, new
APIs `otGetLogLevel()` and `otSetLogLevel()` are added to handle
per-instance log levels.
Specifically, this commit makes the following changes:
- Adds `mLogLevel` to `Instance` to track the instance-specific log
level.
- Renames the global log level static variable to `sGlobalLogLevel` and
introduces `GetGlobalLogLevel()` and `SetGlobalLogLevel()` to manage
it in a multi-instance configuration.
- Updates `otGetLogLevel()` and `otSetLogLevel()` APIs to handle
per-instance log level retrieval and configuration. If a specific
level is not set for an instance, it falls back to the global
log level.
- Adds `mIsLogLevelSet` to distinguish between an explicitly set
instance log level and the global fallback in multi-instance builds.
- Introduces `otPlatLogHandleLogLevelChanged()` platform callback to
notify the platform when an instance-specific log level is updated.
- Updates Nexus tests to use `SetGlobalLogLevel()` instead of the
deprecated instance `SetLogLevel()` method.
Faster and more scalable network simulation: Enable faster and more efficient simulations of OpenThread networks involving a large number of nodes over extended durations.
Enhanced control: Achieve greater control and scalability over simulated tests.
Features
Includes the Nexus platform implementation that emulates platform behavior, allowing multiple nodes running the OpenThread core stack to be simulated and interact with each other within the same process.
Unlike the simulation platform (under examples/platforms/simulation), where nodes run in separate processes and interact via POSIX sockets, Nexus nodes are simulated within a single process.
Nexus tests can interact directly with the C++ or C OT core APIs, providing more control than the simulation platform's CLI-based interactions.
The flow of time in Nexus tests is directly controlled by the test itself, allowing for quick time interval advancement.
How to build and run tests
To build Nexus test cases, the tests/nexus/build.sh script can be used:
top_builddir=nexus_test ./tests/nexus/build.sh
By default, the script builds for IEEE 802.15.4. To build for TREL tests, use the trel argument:
The tests/nexus/run_nexus_tests.sh script automates the process of running tests and performing packet verification using corresponding Python scripts.
The script runs the Nexus C++ test (which generates a JSON file and optionally a PCAP file) and then executes the Python verification script (e.g., verify_5_1_1.py) if it exists. Artifacts for each test are preserved in a temporary directory if the test fails.
Manual execution
Each test can be run directly from the build directory. C++ tests typically take a topology name (if applicable) and a JSON output filename as arguments.
./nexus_test/tests/nexus/nexus_6_1_1 A test_6_1_1.json
Abtin Keshavarzian
cb4b28313b