On 11/30/2012 06:23 PM, Tobias Börtitz wrote:
>  - When sending an asynchronous message, the answer to this message is
> always dropping into the answerbox of the task the original message was
> sent from?

Yes, regardless of any possible forwarding.

>  - The callid of the answer to a previously send message can be
> calculated by adding 1 to the callid of the send message? (so that the
> answer can be assigned to the right message)

Well, IPC_CALLID_ANSWERED (i.e. 1 in the current mainline) is OR'ed to
the callid when the task receives the answer from
sys_ipc_wait_for_call(). The effect of this OR operation on an otherwise
aligned callid (which is currently the kernel address of the call_t
structure) is that it looks as though 1 was added to it. It's more of a
way to let the userspace know that this in fact is an answer to a
previous call. The userspace IPC code then knows that when it masks the
IPC_CALLID_ANSWERED bit off, it will have the hash of the desired call
structure. I suggest you use a similar logic based on the symbolic value
of IPC_CALLID_ANSWERED for pairing the answers with the requests,
otherwise you risk that your pairing will break when someone redefines
the macro.

>  - When an answer arrives, the return code of the answer is located in
> the field args[0] of the returned ipc_call_t struct (which is retrieved
> through a call to IPC_GET_RETVAL())?

Yes, as you can easily verify by a simple experiment.

>  - When an answer arrives, the in_task_id of the ipc_call_t struct is
> always 0 and the in_phone_hash is only sometimes filled? (only tested
> with messages containing the imethod IPC_M_CONNECT_TO_ME)

That sounds wrong. I know this is kind of unintuitive, but in_task_id
and in_phone_hash are actually the userspace names for the kernel's
ipc_data_t::task_id and ipc_data_t::phone members. This piece of the
call is updated by the kernel each time somebody sends, forward or
replies the call. Take a look at kernel's
_ipc_answer_free_call(),_ipc_call_actions_internal() and ipc_forward().
Note that ipc_data_t is the structure which is copied to userspace when
someone waits for a call. They should not be zero most of the time.

Jakub

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel

Reply via email to