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 :
- 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.