|
kusano |
7d535a |
PORTING LIBUSB TO OTHER PLATFORMS
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Introduction
|
|
kusano |
7d535a |
============
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
This document is aimed at developers wishing to port libusb to unsupported
|
|
kusano |
7d535a |
platforms. I believe the libusb API is OS-independent, so by supporting
|
|
kusano |
7d535a |
multiple operating systems we pave the way for cross-platform USB device
|
|
kusano |
7d535a |
drivers.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Implementation-wise, the basic idea is that you provide an interface to
|
|
kusano |
7d535a |
libusb's internal "backend" API, which performs the appropriate operations on
|
|
kusano |
7d535a |
your target platform.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
In terms of USB I/O, your backend provides functionality to submit
|
|
kusano |
7d535a |
asynchronous transfers (synchronous transfers are implemented in the higher
|
|
kusano |
7d535a |
layers, based on the async interface). Your backend must also provide
|
|
kusano |
7d535a |
functionality to cancel those transfers.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Your backend must also provide an event handling function to "reap" ongoing
|
|
kusano |
7d535a |
transfers and process their results.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
The backend must also provide standard functions for other USB operations,
|
|
kusano |
7d535a |
e.g. setting configuration, obtaining descriptors, etc.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
File descriptors for I/O polling
|
|
kusano |
7d535a |
================================
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
For libusb to work, your event handling function obviously needs to be called
|
|
kusano |
7d535a |
at various points in time. Your backend must provide a set of file descriptors
|
|
kusano |
7d535a |
which libusb and its users can pass to poll() or select() to determine when
|
|
kusano |
7d535a |
it is time to call the event handling function.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
On Linux, this is easy: the usbfs kernel interface exposes a file descriptor
|
|
kusano |
7d535a |
which can be passed to poll(). If something similar is not true for your
|
|
kusano |
7d535a |
platform, you can emulate this using an internal library thread to reap I/O as
|
|
kusano |
7d535a |
necessary, and a pipe() with the main library to raise events. The file
|
|
kusano |
7d535a |
descriptor of the pipe can then be provided to libusb as an event source.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Interface semantics and documentation
|
|
kusano |
7d535a |
=====================================
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Documentation of the backend interface can be found in libusbi.h inside the
|
|
kusano |
7d535a |
usbi_os_backend structure definition.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Your implementations of these functions will need to call various internal
|
|
kusano |
7d535a |
libusb functions, prefixed with "usbi_". Documentation for these functions
|
|
kusano |
7d535a |
can be found in the .c files where they are implemented.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
You probably want to skim over *all* the documentation before starting your
|
|
kusano |
7d535a |
implementation. For example, you probably need to allocate and store private
|
|
kusano |
7d535a |
OS-specific data for device handles, but the documentation for the mechanism
|
|
kusano |
7d535a |
for doing so is probably not the first thing you will see.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
The Linux backend acts as a good example - view it as a reference
|
|
kusano |
7d535a |
implementation which you should try to match the behaviour of.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Getting started
|
|
kusano |
7d535a |
===============
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
1. Modify configure.ac to detect your platform appropriately (see the OS_LINUX
|
|
kusano |
7d535a |
stuff for an example).
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
2. Implement your backend in the libusb/os/ directory, modifying
|
|
kusano |
7d535a |
libusb/os/Makefile.am appropriately.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
3. Add preprocessor logic to the top of libusb/core.c to statically assign the
|
|
kusano |
7d535a |
right usbi_backend for your platform.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
4. Produce and test your implementation.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
5. Send your implementation to libusb-devel mailing list.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
Implementation difficulties? Questions?
|
|
kusano |
7d535a |
=======================================
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
If you encounter difficulties porting libusb to your platform, please raise
|
|
kusano |
7d535a |
these issues on the libusb-devel mailing list. Where possible and sensible, I
|
|
kusano |
7d535a |
am interested in solving problems preventing libusb from operating on other
|
|
kusano |
7d535a |
platforms.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
The libusb-devel mailing list is also a good place to ask questions and
|
|
kusano |
7d535a |
make suggestions about the internal API. Hopefully we can produce some
|
|
kusano |
7d535a |
better documentation based on your questions and other input.
|
|
kusano |
7d535a |
|
|
kusano |
7d535a |
You are encouraged to get involved in the process; if the library needs
|
|
kusano |
7d535a |
some infrastructure additions/modifications to better support your platform,
|
|
kusano |
7d535a |
you are encouraged to make such changes (in cleanly distinct patch
|
|
kusano |
7d535a |
submissions). Even if you do not make such changes yourself, please do raise
|
|
kusano |
7d535a |
the issues on the mailing list at the very minimum.
|
|
kusano |
7d535a |
|