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" for requests, "SFCO" for responses) as u32.
| 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 u64 for requests, [[Error_codes|error code]] as u64 for responses.
| 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 or return values
| 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 input rawdata struct 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.
 
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 ==