(Revision 0 - 27 November 2000)
overview ipc_long handles ipc calls that involve deceiving, in memory messages or mappings. The first part determines whether the "deception" is legal, essentially (I think) whether a thread can specify itself as the sender of a message when it isn't. This is ok if the message goes through a chief because it has to cross a clan boundary. If deception is allowed (because the "direction test" is passed), then the originator is specified as the sender of the message (i.e., the originator becomes the "virtual" sender) rather than the chief who is the "actual" sender.
on entry sdesc source descriptor v0 result word v1 sender tid vsend virtual sender
output v1 sender (virtual or actual) from first v0 info for result vector part
data L4_IPC_DECEIT_MASK 0x01 (d bit in source descriptor) L4_IPC_SRC_MASK 0x08 (i bit in result word)
| 0,1 | if no deceit to check for, goto ipc_long second part |
| 2-4 | if specified virtual sender is not a valid thread, goto code stating that this is so |
| 5,6 | save result word in t3 and actual sender in s8 for later use |
| 7-9 | put actual sender in t2 and virtual sender in v1and jump to long_ipc_nchief to determine direction from actual sender (chief) to virtual sender (originator) |
| 11-13 | put actual sender in t2 and destination in v1 and jump to long_ipc_nchief to determine direction from actual sender (chief) to destination |
| 10,14-16 | if the directions for the above two transfers are not different goto line 20 |
| 17-19 | if the directions are different, i.e., the deceit is legal, specify the virtual sender as the actual sender and set the deceit bit in the result word and goto ipc_long second part |
| 20-21 | restore actual sender and original result word and goto ipc_long second part |