Currently there is no way to distinguish between a caller explicitly asking for a semaphore with a limit that happens to be `UINT_MAX` and a semaphore that just has a limit "as large as possible". Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin to `K_FOREVER` versus just passing some very large wait time. In addition, the `k_sem_*` APIs were type-confused, where the internal data structure was `uint32_t`, but the APIs took and returned `unsigned int`. This changes the underlying data structure to also use `unsigned int`, as changing the APIs would be a (potentially) breaking change. These changes are backwards-compatible, but it is strongly suggested to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with `UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT` where appropriate. Signed-off-by: James Harris <james.harris@intel.com> |
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| Kconfig | ||
| prj.conf | ||
| README.rst | ||
| sample.yaml | ||
.. _packet-socket-sample: Packet socket sample #################### Overview ******** This sample is a simple packet socket application showing usage of packet sockets over Ethernet. The sample prints every packet received, and sends a dummy packet every 5 seconds. The Zephyr network subsystem does not touch any of the headers (L2, L3, etc.). Building and Running ******************** When the application is run, it opens a packet socket and prints the length of the packet it receives. After that it sends a dummy packet every 5 seconds. You can use Wireshark to observe these sent and received packets. See the `net-tools`_ project for more details. This sample can be built and executed on QEMU or native_posix board as described in :ref:`networking_with_host`. .. _`net-tools`: https://github.com/zephyrproject-rtos/net-tools