There could be cases where the destroy callback needs more
fine-grained control of step ordering than "1. destroy, 2. put back to
free FIFO". One case could be when the the pool needs to be protected
by a microkernel mutex or semaphore. In such a case the putting back
to the FIFO may need to happen before a custom action in the destroy
callback.
Making the destroy callback responsible for returning to the free FIFO
gives full flexibility regarding the order of the cleanup actions.
Change-Id: Ib9532d1dd70e0a2042af54ebd3e40a853dd42d33
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We need to have a generic buffer API in order to efficiently transfer
data between different subsystems. The first such case will be the
Networking and Bluetooth subsystems where 6LoWPAN data will be passed
back and forth.
The needed API needs to provide enough flexibility for different
buffer sizes as well as custom protocol-specific context data.
The implementation offered in this patch follows the general design of
the existing Networking and Bluetooth buffer implementations by using
a backing array of buffer which is fed into a "free buffers" FIFO for
management. The main difference is that the API allows specifying
variable sized buffers for each created pool, as well as a minimum
amount of "user data" that's allocated as part of each buffer.
There's also an optional destroy callback that's e.g. useful for HCI
flow control in Bluetooth (for notifying the controller of available
buffers).
Change-Id: I00b7007135a0ff35219f38f48658f31728fbb7ca
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Johan Hedberg