An allocation is pinned by calling buflib_pin() to up its pin count.
The pin count is like a reference count: when above 0, buflib won't
move the allocation and won't call its move callbacks. This makes it
safe to hold the pointer returned by buflib_get_data() across yields
or allocations.
Note that pinned allocations can still shrink because there are some
use cases where this would be valid, if buffer users coordinate with
the shrink callback.
Change-Id: I0d0c2a8ac7d891d3ad6b3d0eb80c5b5a1b4b9a9d
Using a length 1 char array to point to the name buffer triggers
a -Warray-bounds warning from GCC when fortified strcpy is used.
This type of construct isn't safe in general -- if the compiler
makes assumptions based on the array bound it can create subtle
bugs when accessing the array out of bounds.
Instead, add a function get_block_name() which returns a pointer
to the name field by casting. This suppresses the warning and it
should be a bit more portable.
Change-Id: I25d4f46f799022ad0ec23bef0218f7595cc741ea
These don't have any users and there is already another way to
print blocks (which is actually used by the debug menu).
Change-Id: Ic6a4f874c6499c42bc046e8af3e4aaddc9e68276
There are various allocations that can't be moved or shrunk.
Provide a global callback struct for this use case instead of
making each caller declare its own dummy struct.
Also fixed ROLO and x1000 installer code which incorrectly
used movable allocations.
Change-Id: I00088396b9826e02e69a4a33477fe1a7816374f1
Document the fact that buffers are movable by default.
Care must be taken to not pass them to functions that yield().
Also clarify other things:
- Passing NULL as "ops" to buflib_alloc_ex() causes
buffers to be movable by default (but not shrinkable).
- If you want shrinkable buffers during compaction,
you have to provide a shrink callback.
- To disable buffer movement, you have to pass NULL
for the move_callback inside the callback structure.
- The concept of default callbacks was removed
long ago, remove the only reference of it.
Change-Id: I3bf0ea6b08b507d80a19f3c2c835aca32b3f7800
This allows buflib clients to more accurately estimate the total memory usage.
It's still not 100% accurate because the handle table grows in blocks, thus
buflib might use more memory that caused by allocations directly.
Change-Id: I68338bb94f510ad188fcb588aebf895b5f9197c5
This should catch the case of buffer misuse which results
in corrupted cookie of next allocation. The check is performed
on move_block() so it may be a bit late.
There is buflib_check_valid() provided which checks the
integrity of all cookies for given context.
On DEBUG build with --sdl-thread this check is carried out
for core_ctx on every context switch to catch problems earlier.
Change-Id: I999d4576084592394e3dbd3bdf0f32935ff5f601
Reviewed-on: http://gerrit.rockbox.org/711
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
This function relocates a buflib back buffer, updating pointers in struct
buflib_context. It does not move any data by itself.
The intended use-case is buflib-on-buflib, where a buflib back buffer is
allocated with buflib and attempted to be moved. The move_callback() can call
this and return BUFLIB_CB_OK on success. No move_callback() is called for the
subordinate buflib buffer, therefore it must not contain non-movable
allocations. The caller is generally responsible moving the data and all its
implications.
Change-Id: I869219f9cff786a172c9e917a5f34470073892e6
This function will now ask shrinkable allocations to give up all of their
memory. With future support of playback.c this can be used as a safe
replacement for audio_get_buffer().
Change-Id: I290a51d2c75254e66baf5698c41dc444dea6247a
buflib_allocatable() is what buflib_available() was before (it was in fact
simply renamed). It returns the largest contiguous block of memory. This
can be allocated and will definitely succeed, although larger allocations
may also succeed if the buffer can be compacted and shrinked.
buflib_available() now counts all free bytes, contiguous or not. This
better matches the description and how the caller use it.
Change-Id: I511e4eb5f4cf1821d957b3f4ef8a685ce40fe289
Reviewed-on: http://gerrit.rockbox.org/481
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
Tested-by: Thomas Martitz <kugel@rockbox.org>
Buffers are not allocated and thread is not created until the first
call where voice is required.
Adds a different callback (sync_callback) to buflib so that other
sorts of synchonization are possible, such as briefly locking-out the
PCM callback for a buffer move. It's sort of a messy addition but it
is needed so voice decoding won't have to be stopped when its buffer
is moved.
Change-Id: I4d4d8c35eed5dd15fb7ee7df9323af3d036e92b3
* Enhance allocation function comments to better state the return value and what an invalid value is
* Change clients to check for "< 0" instead of "<= 0" or "== 0"
* Return -1 or -2 depending on the exact failure in buflib_alloc_ex.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30469 a1c6a512-1295-4272-9138-f99709370657
The buflib memory allocator is handle based and can free and
compact, move or resize memory on demand. This allows to effeciently
allocate memory dynamically without an MMU, by avoiding fragmentation
through memory compaction.
This patch adds the buflib library to the core, along with
convinience wrappers to omit the context parameter. Compaction is
not yet enabled, but will be in a later patch. Therefore, this acts as a
replacement for buffer_alloc/buffer_get_buffer() with the benifit of a debug
menu.
See buflib.h for some API documentation.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30380 a1c6a512-1295-4272-9138-f99709370657
