Hi I used launchpad to start a hello_client and hello_server.I closed hello_server and expected the call from hello_client could cause an ipc error ,because the target is not exist .
I modify the l4_ipc_call function in file ipc-l42-gcc-nopic.h
L4_INLINE l4_msgtag_t l4_ipc_call(l4_cap_idx_t dest, l4_utcb_t *u, l4_msgtag_t snd_tag, l4_timeout_t timeout) L4_NOTHROW { l4_umword_t dummy1, dummy2, dummy3; l4_msgtag_t rtag;
(void)u; __asm__ __volatile__ (L4_ENTER_KERNEL : "=d" (dummy3), "=D" (dummy1), "=c" (timeout), "=S" (dummy2), "=a" (rtag.raw) : "S" (0), "c" (timeout), "d" (dest | L4_SYSF_CALL), "a" (snd_tag.raw) : "memory", "cc" L4S_PIC_CLOBBER ); // add by wyq int ipc_error = l4_ipc_error(rtag,u);
if(ipc_error==L4_IPC_ENOT_EXISTENT ||ipc_error==L4_IPC_RECANCELED) { outstring("Ipc not exist or canceled "); } // end
return rtag; }
outstring is defined in <l4/sys/kdebug.h>,i am sure it can be used here.
I can not get the output and i don't know why.
Thanks & Regards
Hi,
On Thu, Sep 26, 2013 at 12:30:28AM +0800, yuqing wang wrote:
I used launchpad to start a hello_client and hello_server.I closed hello_server and expected the call from hello_client could cause an ipc error ,because the target is not exist .
[...]
if(ipc_error==L4_IPC_ENOT_EXISTENT ||ipc_error==L4_IPC_RECANCELED) { outstring("Ipc not exist or canceled "); } // end
Maybe you can print the ipc_error value in the else case to see which value it has?
Best, Matthias.
Hello Yuqing Wang,
I used launchpad to start a hello_client and hello_server.I closed hello_server and expected the call from hello_client could cause an ipc error ,because the target is not exist .
I cannot give you details about the Fiasco.OC-specific part of your question but I welcome the discussion about IPC errors in general.
Recently, I came to the realization that we should remove the notion of IPC errors from the Genode API. Why is that? In general, a client that calls a server ultimately has to accept that the call may never return. Such a call is similar to calling into any piece of unknown code such as a 3rd-party library. For example, the call may never return because the server has entered an infinite loop. For the client, it make no difference whether the server behaves that way or the server does not exist at all.
In your case, the parent intentionally killed the server process. If the client receives an IPC error, it gains the bit of knowledge that the server does not exist anymore. But maybe the parent wants to hide the fact? When reflecting such a condition in the form of an error code, the parent has no means to hide this information from the client.
Currently, there exists the 'Ipc_error' exception but I cannot come up with a use case where the knowledge about an IPC error actually helps the client. In current Genode components, this condition remains unhandled anyway and lets the client process abort. In the case where a server disappears (note that this condition is always mandated by the common parent of both client and server), it makes hardly any difference whether the client process aborts or simply gets stuck. The parent wanted to get its child into trouble - so be it.
Finally, the conditions for IPC errors are not consistent across the Genode base platforms. An IPC error is always some exceptional condition but its root cause varies. For example, on Linux, an IPC error occurs when the client cannot create a socket pair (e.g., due to a resource limit). On OKL4, an IPC error is merely raised during a failed send phase of an IPC. On NOVA, IPC errors are never raised in the platform-specific code. Because of these differences, platform-agnostic code generally cannot draw a meaningful conclusion about handling such an IPC error.
It sounds like you have a valid use case for responding to IPC errors. If yes, I would very much appreciate to learn about it.
Cheers Norman
Hi， I want to get the IPC error because I want to recover a crashed component. I have read a paper about trust recovery in L4RE,I just want to try the same work on Genode. I modity the fourth parameter of L4_IPC_CALL ,now I can get a timeout error,so I can continue my research.
Regards
2013/9/26 Norman Feske <norman.feske@...1...>
Hello Yuqing Wang,
I used launchpad to start a hello_client and hello_server.I closed hello_server and expected the call from hello_client could cause an ipc error ,because the target is not exist .
I cannot give you details about the Fiasco.OC-specific part of your question but I welcome the discussion about IPC errors in general.
Recently, I came to the realization that we should remove the notion of IPC errors from the Genode API. Why is that? In general, a client that calls a server ultimately has to accept that the call may never return. Such a call is similar to calling into any piece of unknown code such as a 3rd-party library. For example, the call may never return because the server has entered an infinite loop. For the client, it make no difference whether the server behaves that way or the server does not exist at all.
In your case, the parent intentionally killed the server process. If the client receives an IPC error, it gains the bit of knowledge that the server does not exist anymore. But maybe the parent wants to hide the fact? When reflecting such a condition in the form of an error code, the parent has no means to hide this information from the client.
Currently, there exists the 'Ipc_error' exception but I cannot come up with a use case where the knowledge about an IPC error actually helps the client. In current Genode components, this condition remains unhandled anyway and lets the client process abort. In the case where a server disappears (note that this condition is always mandated by the common parent of both client and server), it makes hardly any difference whether the client process aborts or simply gets stuck. The parent wanted to get its child into trouble - so be it.
Finally, the conditions for IPC errors are not consistent across the Genode base platforms. An IPC error is always some exceptional condition but its root cause varies. For example, on Linux, an IPC error occurs when the client cannot create a socket pair (e.g., due to a resource limit). On OKL4, an IPC error is merely raised during a failed send phase of an IPC. On NOVA, IPC errors are never raised in the platform-specific code. Because of these differences, platform-agnostic code generally cannot draw a meaningful conclusion about handling such an IPC error.
It sounds like you have a valid use case for responding to IPC errors. If yes, I would very much appreciate to learn about it.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clk... _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Matthias Lange -
Norman Feske -
yuqing wang