HIPC: Difference between revisions
m Fix bracket location  | 
				|||
| Line 269: | Line 269: | ||
=== Data payload ===  | === Data payload ===  | ||
This is an array of u32's, but individual parameters are generally stored as u64's.  | This is an array of u32's, but individual parameters are generally stored as u64's.  | ||
Input Header:  | |||
{| class="wikitable" border="1"  | {| class="wikitable" border="1"  | ||
! Word || Description  | ! Word || Description  | ||
|-  | |-  | ||
| 0 || Magic ("SFCI  | | 0 || Magic ("SFCI) as u32.  | ||
|-  | |-  | ||
| 1 || Version as u32. 1 for NewRequest, 0 for Request.  | | 1 || Version as u32. 1 for NewRequest, 0 for Request.  | ||
|-  | |-  | ||
| 2 || Command id as   | | 2 || Command id as u32  | ||
|-  | |-  | ||
| 3 || [1.0.0-4.1.0] Padding [5.0.0+] Token (for NewRequest only, non-domain messages).  | | 3 || [1.0.0-4.1.0] Padding [5.0.0+] Token (for NewRequest only, non-domain messages).  | ||
|-  | |-  | ||
| 4... || Input parameters   | | 4... || Input parameters  | ||
|}  | |}  | ||
[5.0.0+] Version was incremented from 0 to 1, and a token value was introduced into raw_data+12 (regardless of domain or not, in either case it overlaps with padding).  | [5.0.0+] Version was incremented from 0 to 1, and a token value was introduced into raw_data+12 (regardless of domain or not, in either case it overlaps with padding).  | ||
The   | |||
Output Header:  | |||
{| class="wikitable" border="1"  | |||
! Word || Description  | |||
|-  | |||
| 0 || Magic ("SFCO") as u32.  | |||
|-  | |||
| 1 || Version as u32. Always 0.  | |||
|-  | |||
| 2 || [[Error_codes|Result]].  | |||
|-  | |||
| 3 || [1.0.0-13.2.1] Padding [14.0.0+] Interface ID  | |||
|-  | |||
| 4... || Return values  | |||
|}  | |||
[14.0.0+] Padding field at +12 is now interface ID, generated as little endian first four bytes of sha256(<fully qualified interface name>). The version field was not incremented.  | |||
The rawdata struct for input parameters/return values is generated by stable-sorting function parameters by alignment, from low to high. It is likely this is a mistake, as it generates structs with suboptimal possible padding -- Nintendo probably meant to sort from high to low (which would give minimized padding), but couldn't/can't change this without breaking backwards compatibility.  | |||
== Official marshalling code ==  | == Official marshalling code ==  | ||