Back to UTCB IPC

[Ronald Aigner]

Hi Marc,

Marc CHALAND wrote on 03/06/2008 10:28 AM this:
> Hi,
> 
> I am back with my problem with UTCB IPC. To sum up the context :
> I use pure l4env applications. Here is the scenario between my server
> and my client :
> 1. client makes an UTCB IPC to manager. Manager does an
> l4rm_area_reserve, creates a rcv_fpage, creates worker and sends back
> worker thread id to client.
> 2. client allocates memory and associated flexpage and sends it to server.
> 3. UTCB IPC is sent to worker with 3 parameters :
>   - on client side : utcb->values=0xbff00200: arg1=0x2 arg2=0x1 arg3=0x6
>   - on server side : utcb->values=0xbff00200: arg1=0x241401 arg2=0x0
> arg3=0x7069776c
This should not happend, because sending a flexpage with UTCB is 
currently not supported by Fiasco. Can you post the signature of this 
method, so I can debug the code generation?

> It seems that 0xbff00200 is not mapped on the same memory on client
> and server side.
Right, because UTCBs are unique for each thread, each thread has its own 
UTCB at a different virtual address. However, the same local threads in 
different address spaces--for instance, thread 8.2 and 9.2-- *may* have 
their UTCB mapped to the same virtual address.

> As there is no problem for first IPC (utcb->values is
> also 0xbff00200), is there any potential problem with flexpage ?
UTCB values stays the same. It depends on the generated stub whether 
UTCB IPC is actually used or not. Sending a flexpage, usually 
disqualifies the usage of UTCB IPC.

BTW: Using the same CORBA_Environment for different threads will have 
the effect that a wrong UTCB is used. The generated stub will access the 
UTCB stored in the environment. The actual IPC will use the UTCB of the 
thread sending the IPC. It is therefore important to initialize the 
environment in the thread that is using it.

> 
> As utcb->values is still the same, what happens if several threads try
> to make UTCB IPC ?
A UTCB is unique for each L4 thread, i.e., each thread has it's own UTCB.

> 
> Another question : when I link my application with liblogserver.a, I
> have strange logs :
> .rm.sem.mainMain function returned.
> It seems that .rm .sem and .main are added by l4env, but I didn't find where.
If you are linking with liblogserver.a you should have a log server running.

These suffixes are registered at names (and the kernel debugger) to ease 
debugging.
rm: l4/pkg/l4env/lib/src/startup.c: 316
main: l4/pkg/l4env/lib/src/startup.c: 322
sem: l4/pkg/semaphore/lib/src/semaphore.c: 501

Regards, Ron.

-- 
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/