Must now be h->size, not sizeof (type).

Change-Id: Ia0b1b552a486ddbc28b80542cfa76bed9e7cfdb3

Change-Id: I0e5a20e042291180391b0b0059e44705c256d3e5

Playback checked the files' presence before attempting to buffer
the track. Just get rid of that and save an extra open/close call.
It will find out if the path is bad when the metadata fails.

Fix some size_t/off_t conflation. No need to update plugin version
because no plugin actually uses bufopen().

Change-Id: I3db112449dc0b2eeb91c546f308880ac82494fc7

Paths are stored after the structure at their actual length plus
any aligment padding. In principle, any type of auxilliary data
could go there.

Change-Id: Ic5487dc4089781b5cc52414d1691ba6d9dc1893c

The location of the handle cannot be kept across calls to
shrink_handle() since it may move the structure. The error was
there in one place at the inception, corrected, then reintroduced.

Make shrink_handle() return the new location and use it, which
makes the side effects of the function clearer.

Change-Id: Icae6a0ad6f7bb0d6645b044cccfa4aef88db42ad

There's no need for it any longer since the list is now doubly-
linked. As a bonus, stack limits pose no barrier to the length of
the list.

Change-Id: I41c567f946b640ef1e3c2d93da2f5aef9a763c66

Does away the statically-allocated track list which frees quite
a fair amount of in-RAM size.

There's no compile-time hard track limit.

Recommended TODO (but not right away): Have data small enough use
the handle structure as its buffer data area. Almost the entire
handle structure is unused for simple allocations without any
associated filesystem path.

Change-Id: I74a4561e5a837e049811ac421722ec00dadc0d50

It sort of implemented an MRU cache but just kept track of the most
recent access and checked the one after it, otherwise searching from
the beginning.

Implement a true MRU list of all open handles. Handles of the current
track will tend to stay up front for faster access.

Switch to common linked list functions

Use double-linked lists to have insert, remove and move_handle
operations in O(1)-- no more searching to find the previous handle,
which is very often required.

Smaller code too. :)

Change-Id: I9ae8f3f96d225a5d54b94133f499268007274784

I'm not sure all the situations it affects, to be honest. The fix
aimed to address the strange symptom here:
http://forums.rockbox.org/index.php/topic,50793.0.html

It turns out that ringbuf_add_cross was used when handles were
butted up against one another with the first parameter equal to
the last, which it interprets as being an empty case when it should
be interpreted as full in the context it was used. To fix this,
introduce full/empty variants of ringbuf_add_cross and ringbuf_sub
and use them at the appropriate time.

The other way to address the problem is ensure there's always at
least a space byte between the end of one handle and the start of
another but this make the code a bit trickier to reason about than
using additional function variants.

bufopen() may yield after creating a handle and so do some more
locking so that the buffering thread doesn't mess things up by
moving anything or not seeing the yet-to-be linked-in allocation.

Add alignof() macro to use proper method to get alignment of
struct memory_handle. That should be useful in general anyway.
It's merely defined as __alignof__ but looks nicer.

Change-Id: If21739eaa33a4f6c084a28ee5b3c8fceecfd87ce

Change-Id: I10aac94906607a74f05a687cb3d0029cb6faea6e