IPC: Difference between revisions
Fix PXI buffer size shift |
mNo edit summary |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 5: | Line 5: | ||
=== Sessions === | === Sessions === | ||
Sessions are communication channels consisting of a client and server, through which data can be exchanged in the form of a request and response, respectively. Through sessions, the standard [[# | Sessions are communication channels consisting of a client and server, through which data can be exchanged in the form of a request and response, respectively. Through sessions, the standard [[#Message Structure|IPC command protocol]] is implemented. Clients use their client session handle to send IPC commands to the server using svcSendSyncRequest, while servers use svcReplyAndReceive to reply. Client sessions can't be used with svcReplyAndReceive. In both cases, the kernel takes care of transferring IPC command data from the [[Thread Local Storage]] of the sending thread to the TLS of the receiving thread. Sessions can be created through svcCreateSession, which provides the caller with the client and server handles. | ||
Sessions are used in their raw form to implement [[FS:OpenFile|file handles]]. In this case, fs-module creates a raw session using svcCreateSession, and provides the "fs:USER" client with the resulting client session handle, keeping the server session handle for its own use. These sessions expose their [[Filesystem services#File service|own set of IPC commands]] which act on the file that was opened through fs:USER. | Sessions are used in their raw form to implement [[FS:OpenFile|file handles]]. In this case, fs-module creates a raw session using svcCreateSession, and provides the "fs:USER" client with the resulting client session handle, keeping the server session handle for its own use. These sessions expose their [[Filesystem services#File service|own set of IPC commands]] which act on the file that was opened through fs:USER. | ||
| Line 99: | Line 99: | ||
|- | |- | ||
| 4 | | 4 | ||
| If set, the handles are closed for the caller | | If set, the handles are closed for the caller. | ||
|- | |- | ||
| 5 | | 5 | ||
| Line 108: | Line 108: | ||
|} | |} | ||
Usage examples: | Setting both bit4 and bit5 causes a kernel panic. Usage examples: | ||
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
|- | |- | ||
| Line 219: | Line 220: | ||
| 0x0000000E <nowiki>|</nowiki> (size<<4) | | 0x0000000E <nowiki>|</nowiki> (size<<4) | ||
<ptr> | <ptr> | ||
| The corresponding value contains a ptr to a buffer of said size. The buffer specified by the source process must have read permission during cmd-request handling(write permission is checked during cmd-reply handling for the original buffer). | | The corresponding value contains a ptr to a buffer of said size. The buffer specified by the source process must have read permission during cmd-request handling(write permission is checked during cmd-reply handling for the original buffer). Some calls like [[CECDU:WriteMessageWithHMAC]] use it, however it is unsure as to why. When handling command requests this is handled the same way as 0x0000000A, and for handling command replies this is handled the same way as 0x0000000C(besides the descriptor type written into the dst cmdbuf for both of these). | ||
|} | |} | ||
| Line 267: | Line 268: | ||
while (true) { | while (true) { | ||
Result res = svcReplyAndReceive(&requesting_index, | Result res = svcReplyAndReceive(&requesting_index, handles, 1 + connected_clients, reply_target); | ||
if (res == 0xC920181A) { | if (res == 0xC920181A) { | ||