[EMAIL PROTECTED] wrote:
> 
> On Thu, Sep 07, 2000 at 06:58:48AM +0200, Paolo Mantegazza wrote:
> > [EMAIL PROTECTED] wrote:
> > - ..... do we want to bet how long will it take to see a real time
> > memory manager in RTL?
> 
> There is no such thing as a dynamic real time memory manager.

In fact I was just betting there will be one in the future :-).
 
> It's been some years since RTL has been available and we have
> many times had this silly discussion.
>
> The code for a simple version is trivial.
> 
> 
> Step 1: write some module code:
> In Linux init:
>                ask for a soft RTL interrupt
>                install a handler
> 
>          handler:
>                   read from request queue (could be a fifo)
>                   v = kmalloc( requested.space)
>                   *requested.result = v;
>                   pthread_wakeup_np(requested.thread);
> 
> Step 2: write some RTL thread code.
> 
> In  rtl  periodic thread;
> 
>            queue request.
>            pthread_kill(pthread_linux(),kmalloc_irq);
>            while( !request.result)
>                  pthread_wait_np();
> 
> Step3 : receive Nobel Prize.

Since you like joking, I feel invited to go on ;-).

Once more RTAI has no problem in doing that. RTAI fifos were already
based on the use of its srqs when RTL was still patching the kernel to
protect Linux tasks queues to be used with fifos in real time.

In fact we (I, Steve and Pierre) discussed a similar solution before
they implemented theirs ideas, but they denied its usefulness because
was too much not deterministic, and they needed a truly fast minimal
latency dynamic memory manager for their applications.
So I was just pleased to have them add, and copyright, what I think is
an usefull service for RTAI. Recall that I support the idea that a reach
toolbox of mechanisms enhances user politics implementation freedom.

Note also that RTAI calls what you name soft interrupts as system
requests and they are structured with two handlers, one for user and one
for kernel space. So it could be simple for a supervisory user space
process, acting as a user interface, to pre allocate memory in kernel
space for a new stack of a to be launched rt_task, or a larger one onto
which save an already in use stack, so that a real time task could be
dynamically resumed on a larger stack if needed, and many other fancy
things. However all those things were believed not satisfactory, because
tightened to Linux, and thus miles away from a minimal latency memory
management.

Nonetheless RTAI exploits the idea of using an srq in relation to memory
managment, but just for kfreeing kmalloced memory when tasks are
deleted.

Clearly I applied to have a Nobel Prize. They already promised me one
when the euro will be worth .001 dollars, and it seems it will happen
quite soon.

Ciao, Paolo.
-- [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