From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7806 invoked by alias); 3 Nov 2003 22:38:49 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 7799 invoked from network); 3 Nov 2003 22:38:48 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sources.redhat.com with SMTP; 3 Nov 2003 22:38:48 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1AGnLS-0002gU-00; Mon, 03 Nov 2003 23:38:46 +0100 Date: Mon, 03 Nov 2003 22:38:00 -0000 To: Thomas Koeller Cc: ecos-discuss@sources.redhat.com Message-ID: <20031103223846.GB7648@lunn.ch> Mail-Followup-To: Thomas Koeller , ecos-discuss@sources.redhat.com References: <200311031538.57806.thomas.koeller@baslerweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311031538.57806.thomas.koeller@baslerweb.com> User-Agent: Mutt/1.5.4i From: Andrew Lunn Subject: Re: [ECOS] jffs2 memory allocation X-SW-Source: 2003-11/txt/msg00022.txt.bz2 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