This is the mail archive of the
mailing list for the eCos project.
Re: blib kernel dependency patch
- From: Savin Zlobec <savin at elatec dot si>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: ecos-patches at sources dot redhat dot com
- Date: Tue, 29 Jun 2004 10:27:46 +0200
- Subject: Re: blib kernel dependency patch
- References: <40DFE166.firstname.lastname@example.org> <20040629070005.GH7220@lunn.ch>
Andrew Lunn wrote:
On Mon, Jun 28, 2004 at 11:14:14AM +0200, Savin Zlobec wrote:
this patch changes the cyg_mempool_fix_* based internal blib block
memory pool managment
with custom (much simpler) block memory pool funs. With this change blib
no more depends on
the kernel package.
I don't think the memalloc package is dependent on the kernel. There
is something in the docs/notes.txt about this. Do we realy need yet
another set of memory allocation functions?
Having said that, i've never tried to use the package without the
kernel. So i've no idea how easy it is to make it work.
The cyg_mempool_fix/var* API funs are defined in the file kapi.cxx which
compilation is conditioned in memalloc.cdl with 'active_if CYGPKG_KERNEL'.
The file consists only of C wrappers for Cyg_Mempool_Variable and
Cyg_Mempool_Fixed C++ objects (which don't depend on the kernel), but
this are the only C wrappers for this two objects.
Regrardless of that the new implementation of block memory pool is
smaller/faster than using cyg_mempool_fix API. Each block header
already contained the 'struct list_head' linked list pointers which are
now used also for linking free blocks in a free block list. The new
implementation doesn't require more RAM, the block allocation and
freeing is more simple/faster (a matter of taking the first block
from the linked list or putting it back), the code size increment is just
a couple of lines and it doesn't require the memalloc package any more.
I'am in the process of reworking the fatfs to get rid of malloc and any
kernel dependencies - I have already a working version without the FAT
table entries cache which didn't provide any performance gain with most
file ops and slowed/complicated access with bigger files. Now the fileio1
test flyes and it all should compile in nonkernel configurations.