Traditionally, a CryptoServer firmware module will have three different types of usable methods: External, Public and Internal.
External methods (names marked with `\ext` by convention) are those referred to as subfunction codes in the example module or in the developer documentation. These are the methods that can be addressed directly from a host application, via `cs_exec_command()` or the `cxi::exec()` command, or similar (depending on API).
Public methods (marked by `\pub` by convention) are accessible by other modules within the runtime context. When a module wants to access the public API of a different module, it will be provided with the address of the target module's public methods at boot time. Because these are called via the compiler's defined calling conventions (accessed via a function pointer), passing data to/from them is handled via the call stack. For this reason, serialization / deserialization of data is usually not necessary (or is handled by the calling method, before calling a Public function).
Internal methods (unmarked, or marked by `\int`) are only visible to the target module itself. These are linked at compile time, and no external symbol is provided in the object.
Again, ordinarily, on the HSM it is only the `\ext` methods that need to worry about deserialization on the CryptoServer, or serialization of data for return to the host application.
To assist in deserialization, the `cmds` module's public API includes `cmds_scanf()`, which is a limited-copy parser of structured byte-buffer data. Aside from macros and low-level methods used to append data to a byte buffer, no support is provided for buffer serialization
(on the host or on the CryptoServer). The developer is expected to konw the order, endinanness and protocols for packing the buffer.