Back to UTCB IPC
ra3 at os.inf.tu-dresden.de
Thu Mar 6 11:34:12 CET 2008
Marc CHALAND wrote on 03/06/2008 10:28 AM this:
> 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
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
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
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
More information about the l4-hackers