| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 2729 |
6114 d 9 h |
decky |
/branches/network/ |
add networking branch |
|
| 2677 |
6157 d 3 h |
jermar |
/trunk/ |
Rename IPC_M_AS_AREA_SEND to IPC_M_SHARE_OUT. Rename IPC_M_AS_AREA_RECV to
IPC_M_SHARE_IN. Provide user-friendly wrappers for these methods so that even
dummies can get it right. Some applications using simpler protocols still use
these methods directly. |
|
| 2676 |
6157 d 10 h |
jermar |
/trunk/ |
Simplify the IPC_M_DATA_WRITE protocol. Do not pass the source address space
virtual address to the recipient. This feature was not used anyway. Now
IPC_M_DATA_WRITE and IPC_M_DATA_READ are feature-aligned. |
|
| 2662 |
6164 d 23 h |
jermar |
/trunk/ |
Add support for IPC_M_DATA_READ calls. |
|
| 2661 |
6165 d 0 h |
jermar |
/trunk/kernel/generic/src/ipc/ |
Release the IPC_M_DATA_WRITE buffer even if the write is refused by the
recipient. |
|
| 2660 |
6165 d 0 h |
jermar |
/trunk/ |
Rename IPC_M_DATA_SEND to IPC_M_DATA_WRITE. Now, when we also add
IPC_M_DATA_READ, it will not clash and cause confusion with userspace wrappers
such as ipc_data_receive(). Rename the forementioned wrappers to
ipc_data_write_send(), ipc_data_write_receive() and ipc_data_write_deliver(). |
|
| 2638 |
6184 d 0 h |
jermar |
/trunk/ |
Sync IPC comments with IPC code. |
|
| 2637 |
6184 d 0 h |
cejka |
/trunk/ |
Extended IPC_M_CONNECT_TO_ME to use 3 user defined parameters.
Phone identifier is passed in ARG5. |
|
| 2636 |
6185 d 23 h |
jermar |
/trunk/ |
Update comments wrt the previous commit.
Minor formatting fixes. |
|
| 2635 |
6186 d 0 h |
cejka |
/trunk/ |
Function ipc_connect_me_to sends 3 user defined arguments now.
One argument added also to ipc_forward_fast.
Fixed devmap and improved its test. |
|
| 2626 |
6193 d 10 h |
jermar |
/trunk/kernel/generic/ |
Support for 5 payload arguments for IPC irq notifications and the pseudo code. |
|
| 2623 |
6194 d 6 h |
jermar |
/trunk/kernel/generic/ |
Introduce the IPC_FF_ROUTE_FROM_ME forwarding flag. |
|
| 2622 |
6194 d 6 h |
jermar |
/trunk/ |
Add mode argument to IPC forward.
This argument can be used to modify the way forward behaves. |
|
| 2620 |
6196 d 11 h |
jermar |
/trunk/ |
Be more deterministic when a user accidently uses fast version of IPC
call/answer instead of the full one and passes fewer arguments than required by
the recipient of the call/response.
and the recipient interprets arguments that
were actually not passed by the sender. |
|
| 2619 |
6197 d 23 h |
jermar |
/trunk/ |
Modify ipc_answer_*() to make use of all six syscall arguments. The recommended
means of answering calls is via the ipc_answer_m() macros (where m denotes the
number of return arguments) that automatically decide between the fast register
version or the slow universal version of ipc_answer(). |
|
| 2618 |
6198 d 11 h |
jermar |
/trunk/ |
Modify asynchronous IPC to make use of all six syscall arguments. The preferred
means of asynchronous communication is now via the set of ipc_call_async_m()
macros, where m is the number of payload arguments passed to the kernel. These
macros will automatically decide between the fast and the universal slow version
of ipc_call_async. |
|
| 2617 |
6199 d 3 h |
jermar |
/trunk/kernel/generic/src/ipc/ |
STRUCT_TO_USPACE may fail in sys_ipc_call_sync_fast. |
|
| 2615 |
6199 d 8 h |
jermar |
/trunk/ |
Modify synchronous IPC to make use of all six syscall arguments. The preferred
means of synchronous communication is now via the set of ipc_call_sync_m_n()
macros, where m is the number of payload arguments passed to the kernel and n is
the number of return values. These macros will automatically decide between the
fast and the universal slow version of ipc_call_sync. |
|
| 2601 |
6207 d 3 h |
jermar |
/trunk/kernel/generic/src/ipc/ |
Fix and improve two IPC related comments. |
|
| 2557 |
6250 d 8 h |
jermar |
/trunk/kernel/generic/src/ipc/ |
Enable forwarding of IPC_M_AS_AREA_SEND, IPC_M_AS_AREA_RECV, IPC_M_DATA_SEND
calls. In order to prevent the forwarder from cloberring the call data (i.e.
source and destination address, and size) by treating these three methods as
immutable on forward. This feature is experimental, but has huge benefits in
that it can significantly reduce the amount of data sharing (the middle man need
not modify its address space mappings) or the amount of data copying (the middle
man need not receive the data from the sender and then resend them to the next
recipient). As a result, it can reduce N such calls for a communication channel
with N tasks along the way to 1 such call. |
|