[ECOS] jffs2 memory allocation

[ECOS] jffs2 memory allocation

[Thomas Koeller]

As has been stated earlier (see http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00247.html),
the memory allocation routines used by the ecos port of jffs2 could be improved by using a fixed-
size block allocator instead of the current malloc()-based scheme. This could be achieved in two
different ways: A new set of allocator routines could be added to the jffs2 package, to either
replace or complement the existing functions. Or one could simply add a 'weak' attribute to the
existing functions, so the application could redefine them.

The first approach yields something that is easy to use, but there can only be limited control of
the allocation process (by means of configuration parameters). The second approach requires more
work to be done by the user, but also gives better control, which may be beneficial. For example,
I might want to use a separate heap for this purpose.

I feel a bit uncertain about which way to go, so I'd welcome any comments.

tk

--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com

==============================


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] jffs2 memory allocation

[Andrew Lunn]

On Mon, Nov 03, 2003 at 03:38:57PM +0100, Thomas Koeller wrote:

> As has been stated earlier (see
> http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00247.html),
> the memory allocation routines used by the ecos port of jffs2 could
> be improved by using a fixed- size block allocator instead of the
> current malloc()-based scheme. This could be achieved in two
> different ways: A new set of allocator routines could be added to
> the jffs2 package, to either replace or complement the existing
> functions. Or one could simply add a 'weak' attribute to the
> existing functions, so the application could redefine them.
> 

> The first approach yields something that is easy to use, but there
> can only be limited control of the allocation process (by means of
> configuration parameters). The second approach requires more work to
> be done by the user, but also gives better control, which may be
> beneficial. For example, I might want to use a separate heap for
> this purpose.
> 
> I feel a bit uncertain about which way to go, so I'd welcome any comments.

I think i would go a third way. There already appears to be a
reasonably clean interface to the memory allocation/free
functions. Its has one implementation in malloc-ecos.c. I would take
the prototypes out of nodelist.h and put them into an exported header
file.  I would move malloc-ecos.c into a package of its own. Add an
CDL interface which this package implements and make this package the
default implementation of there is no other implementation of the
interface.

Developers are then free to develop other schemes in separate
packages. Hopefully we will then get some of these schemes
contributed.

        Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss