From: Thomas Martitz <thomas.martitz_at_student.htw-berlin.de>
Date: Tue, 07 Jun 2011 18:01:31 +0200

Hey folks.

Due to DevCon this mail is a bit late, but I do had some progress since
my last mail.

Firstly, I finished my analysis and now have a pretty good idea what
buflib needs to provide to support the
current ways of using memory in Rockbox. You can find my complete
analysis at [1].

Going further, I also checked direct audiobuf accesses, which kind of
need to be removed as a requirement. Some analysis of this is in [1],
however I also already worked on removing all direct accesses[2]. That
seems to work (notice that my new buffer_get_buffer has a lock, which
will cause a panicf() if it's re-aquired, but I haven't seen a panicf()
so far).

With this knowledge, I was able to think about an API for buflib in the
core. The current state of this API is at [3], in form of a header file
and with extensive comments. I guess this API needs some discussion
whether it's acceptable because it's desirable to get this right from
the start.

More on the API: I think most function are pretty clear, but I want to
share why I think I need two pieces that are perhaps not so clear (if
others aren't clear, feel free to ask about them).

- core_shrink()/buflib_alloc_maximum(): Some modules need memory without
knowing the exact memory beforehand. Those allocate the maximum and give
back when the know the exact amount (dircache). Others allocate in try
steps in the hope it'll work (tagtree).
Allocating in tiny steps is inefficient now (as each allocation has
metadata), so I would convert tagtree to what dircache does. To make
this work, buflib needs a means to hand out the entire buffer.
buflib_buffer_out() is not suitable since it removes the affected memory
out of buflib's control. Therefore I implement a buflib_alloc_maximum()
which gives out everything and returns a normal handle. It also aquires
a lock which will make allocations in the meantime wait (probably won't
be mutex but something more simple since it's very unlikely that a
allocation actually happens in the meantime).
To give back memory, core_shrink() will be used. It'll unlock the lock
iif the lock was held by the corresponding handle.
But core_shrink isn't only the counterpart of buflic_alloc_maximum(). It
can shrink any allocation and is to be used in the shrink_callback().
Especially the main audiobuffer one when allocations occur after
playback has started.

I already started implementing some of the API and adding some test
cases. You can follow the progress in my off-tree buflib repo at [4].

Lastly, I also worked on dircache[5][6] to make it more buflib-friendly.
As you can see, it's mostly about converting direct pointer accesses to
offsets or array indices, particularly for memory that is exposed
outside of the module.

Best regards.

PS: I'll probably migrate my repo.or.cz rockbox stuff to github some
time soon.

[1]:
https://github.com/kugel-/buflib/blob/master/buffer_alloc_callers_notes.txt
[2]:
http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/gsoc2-audiobuf-accesses
[3]: https://github.com/kugel-/buflib/blob/master/proposed-api.h
[4]: https://github.com/kugel-/buflib
[5]:
http://repo.or.cz/w/kugel-rb.git/shortlog/refs/heads/gsoc2-dircache-rework
[6]: http://www.rockbox.org/tracker/task/12133
Received on 2011-06-07