Resources | Resources |



Stubs and skels

Interfaces are defined in Qualcomm's Interface Definition Language (QIDL), which then generates a header file as well as stubs and skels. The stubs and skels are generated as C files, which are then compiled into OS Services modules.

Stubs and skels transport a method invocation's arguments to the device and the return values (including any 'return via parameter' values) back to the device. Usually, the QIDL compiler generates stubs and skels that are specific to a given interface, however in some cases, especially with legacy interfaces, the remoting is performed by hand.

In a typical invocation, the stub is used on the caller's (typically the PC's) side. The stub implements the interface it's associated with, such as IFileSystem2 in the image below. For each method, the stub will convert the parameters into arrays of bytes and/or numeric handles, and send them over the connection to the other side. The stub remains in the function call, blocking, until the skel processes the message and sends back a response.

On the caller (typically the device) side, the buffers and handles are unmarshalled and turned back into standard C function calls. The stub then calls the local interface using a standard C function call. Any returned values, buffers, or handles are then packaged by the skel and returned to the stub over the connection.

Finally, the stub receives the return values from the skel and sets the appropriate values to be returned in the local memory space. The stub returns the error code sent by the skel.

Stub use is invisible to the user. The stub is also capable of returning errors if the USB Gateway no longer exists. This typically prevents deadlock.