On Tuesday 27 March 2001 20:06, Lothar Krause wrote:
> Gee, I'm just looking for damn simple memory allocator that is bit more
> flexibel than just using malloc. I can hack one, I can write one but I do I
> really have to.

More flexible? Hard real time!? Not as simple as it may sound... :-)


> > > One the other side in realtime I'm restricted to use rtlinux without
> > > touching any internals,
> >
> > Why? What do you mean, exactly?
>
> Well if I read the description of the rtai_mem_mgr right I'd have to either
> use a castrated version or somehow make the timing stuff call the manager
> at appropiate times. However from maintainabilty/work view this is a bad
> decision plus I doesn't helps with the other problem.

Unless you can accept using a fixed size pool, you'll either have to port the 
entire Linux memory management to RTL (removing swap, just for starters), or 
do some kind of delayed pool maintenance in the background. If the RTAI 
memory manager does anything but fixed size pool, I'm pretty sure it's done 
the "background maintenance" way.


> > Right; I'd guess most memory managers for use in applications (based on
> > brk() or similar APIs) should be possible to strip down to do something
> > like that.
>
> No, most would require to recompile a separate module every time I need to
> use a distinct memory buffer, or to mess with it and that is not trivial
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not getting this part...

If you have a memory manager that supports a fixed size pool, it should be 
pretty easy to change it so that you hand that buffer over, rather than 
letting the manager allocate it by itself. Then you can just keep that module 
loaded, and initialize it with whatever buffer you want from you application 
modules.


> > Of course; 99% of developers are *not* kernel hackers, but stay in user
> > space...
>
> Yes, but I guess many people from the rt community ran into the same
> problem fand solved it somehow?

Well, I solved a problem of that kind, but it turned out that I don't really 
need dynamic size objects in the hard real time part of the system. It would 
only complicate things, and make the system less reliable.

Maybe I'll need it again some time, but not right now.


> > > And I don't want to write still another memory
> > > allocator if someone else did this before.
> >
> > Right; there are plenty of them. Grab one, and fix it if you have to.
>
> Yeah, is there some kind of repository for this?

Don't know, but it would be a very nice thing to have...


> Didn't find anything useful via google or so?

Well, I didn't need big blocks, splitting or the fragmentation prevention 
measures to handle that, etc, so I just whipped up a simple class. The 
average "find suitable project on 'net" session takes longer than it took me 
to write that. :-)


> Did you take a look at the DL-malloc source?

No, I've only looked at various documents on the subject, and of course, the 
manager behind kmalloc().

Anyway, I'm still not sure what it is you need, so I probably wouldn't be 
able to point you in the right direction to look for an actual implementation.

Below is the interface of my old memory manager. How do the methods match 
what you need? (The ones marked "--SYSTEM--" would be the interesting side 
here; the rest is just a standard malloc() interface with some extensions.)

//FMM base class
class fmm_base_t
{
//  private:
//      fmm_head_t heads[FMM_BLOCKSIZES];

  public:
        fmm_base_t();
        ~fmm_base_t();

        //--SYSTEM--
        //Calculate the ammount of memory needed for blks blocks of size siz.
        static int size_buffers(int blks, int siz);

        //--SYSTEM--
        //Add buffers to the heap.
        //The block at *p will be split into as many buffers of size bsiz as will
        //fit into the block. The size of the block must be at least siz.
        //RETURN the number of buffers added. o is an error return, and means FMM
        //will not use the memory block at all.
        static int add_buffers(void *p, int siz, int bsiz);

        //--SYSTEM--
        //Remove buffers from the heap.
        //RETURN 0 if operation failed, otherwise a pointer to the removed block.
        static void *rem_buffers(void *p);

        //--SYSTEM--
        //Calculate maximum number of buffers of the specified size that could be
        //allocated.
        //Specifying a size of 0 returns the total number of blocks available.
        //Asking for free blocks of a negative size returns only the number of
        //blocks of "the perfect match" size (to -siz); that is, not blocks of
        //sizes bigger than the minimum "stock" size available.
        static int avail_buffers(int siz);

        //--FAST--
        //Allocate siz bytes. (Do not clear.)
        //RETURN pointer if successful, otherwise 0.
        static void *malloc(int siz);

        //--FAST--
        //Change the size of an allocated block to siz bytes.
        //THE RETURNED BLOCK WILL BE UNINITIALIZED!
        //realloc(0, siz) == malloc(0, siz);
        //realloc(ptr, 0) == free(ptr);
        //RETURN pointer to new block if successful, otherwise 0.
        //(The original block will be untouched if the operation fails.)
        static void *resize(void *p, int siz);

        //--FAST--
        //Free a memory block.
        static void free(void *p);

        //--SLOW--
        //Allocate and clear siz bytes of memory.
        //RETURN pointer if successful, otherwise 0.
        //static void *calloc(int siz);

        //--SLOW--
        //Change size of allocated block to siz bytes.
        //The first min(old size, new size) bytes will be preserved;
        //if new size > old size, the added memory will be uninitialized.
        //realloc(0, siz) == malloc(0, siz);
        //realloc(ptr, 0) == free(ptr);
        //RETURN pointer to new block if successful, otherwise 0.
        //(The original block will be untouched if the operation fails.)
        //static void *realloc(void *p, int siz);
};


(Uuurgh... I'm glad I've changed coding style since then! This looks so messy 
without syntax highlighting... *hehe*)


//David

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Reply via email to