can not get ipc error

[yuqing wang]

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 at ...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.clktrk
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20131008/0274f8ce/attachment.html>