Hello friendly Genode-people,
I am having difficulties unterstanding the handling of the server badge (currently in core only)
As far as I understand, the badge identifies the receipient-object. Therefore the sender encodes the address of the receiving object's capability in the first slot of the send buffer.
On the receiver side, in Server_activation_base::entry(), the badge is used to identify the correct object, whose dispatch() Method is then called.
The server however has to insert the capability into the Object_pool first, which is done at Server_entrypoint::manage().
Now I am currently having problems in core's main function. During Ram_session_client(init_ram_session_cap).ref_account(env()->ram_session-cap()), an IPC call is sent to the "activation"-Thread, during which an invalid badge is used. Consequently the activation thread does not find the corresponding object and returns ERR_INVALID_OBJECT.
This raises the following questions: a) Which object is the correct handler for this call, and b) where is the capability of the receiver allocated and registered at the Object_pool?
I am looking forward to hearing from you.
Many thanks in advance.
Greetings, Steffen
Am 17.05.2010 11:54, schrieb Steffen Liebergeld:
Hello friendly Genode-people,
I am having difficulties unterstanding the handling of the server badge (currently in core only)
Although I hate answering myself, I find find the answer and I am sharing it with you.
It turns out, that the badge that was submitted was invalid. I was able to circumvent this by adapting the Ipc_client::_call Method to set the badge to _dst.local_name(). This works for my scenario.
Greetings, Steffen
Hi Steffen,
Steffen Liebergeld wrote:
Although I hate answering myself, I find find the answer and I am sharing it with you.
It turns out, that the badge that was submitted was invalid. I was able to circumvent this by adapting the Ipc_client::_call Method to set the badge to _dst.local_name(). This works for my scenario.
I don't know, what value you are using as 'local_name' (is this a unique object ID as used for most of the supported kernels?). Great that you found a solution for your current problem.
The way the 'Ipc_istream::badge' is handled depends very much on the underlying kernel. So its hard to give a general answer to your question. Generally speaking, the badge is used at the receiver side to identify the addressed server object. On kernels w/o capability support, each server object has a unique ID, known by both client and server. When invoking the server object, the client supplies the unique object ID as plain-data IPC payload. The server, in turn, uses the received ID as badge, which, in turn, is used to look up the local 'Server_object'. This is the scheme as you probably just noticed. On kernels with capability support, the badge could be implemented differently. For example, if the kernel's receive operation returns the invoked capability selector at the server side, this capability selector could be used as badge.
Cheers Norman
-
Norman Feske -
Steffen Liebergeld