OLD | NEW |
(Empty) | |
| 1 PORTING LIBUSB TO OTHER PLATFORMS |
| 2 |
| 3 Introduction |
| 4 ============ |
| 5 |
| 6 This document is aimed at developers wishing to port libusb to unsupported |
| 7 platforms. I believe the libusb API is OS-independent, so by supporting |
| 8 multiple operating systems we pave the way for cross-platform USB device |
| 9 drivers. |
| 10 |
| 11 Implementation-wise, the basic idea is that you provide an interface to |
| 12 libusb's internal "backend" API, which performs the appropriate operations on |
| 13 your target platform. |
| 14 |
| 15 In terms of USB I/O, your backend provides functionality to submit |
| 16 asynchronous transfers (synchronous transfers are implemented in the higher |
| 17 layers, based on the async interface). Your backend must also provide |
| 18 functionality to cancel those transfers. |
| 19 |
| 20 Your backend must also provide an event handling function to "reap" ongoing |
| 21 transfers and process their results. |
| 22 |
| 23 The backend must also provide standard functions for other USB operations, |
| 24 e.g. setting configuration, obtaining descriptors, etc. |
| 25 |
| 26 |
| 27 File descriptors for I/O polling |
| 28 ================================ |
| 29 |
| 30 For libusb to work, your event handling function obviously needs to be called |
| 31 at various points in time. Your backend must provide a set of file descriptors |
| 32 which libusb and its users can pass to poll() or select() to determine when |
| 33 it is time to call the event handling function. |
| 34 |
| 35 On Linux, this is easy: the usbfs kernel interface exposes a file descriptor |
| 36 which can be passed to poll(). If something similar is not true for your |
| 37 platform, you can emulate this using an internal library thread to reap I/O as |
| 38 necessary, and a pipe() with the main library to raise events. The file |
| 39 descriptor of the pipe can then be provided to libusb as an event source. |
| 40 |
| 41 |
| 42 Interface semantics and documentation |
| 43 ===================================== |
| 44 |
| 45 Documentation of the backend interface can be found in libusbi.h inside the |
| 46 usbi_os_backend structure definition. |
| 47 |
| 48 Your implementations of these functions will need to call various internal |
| 49 libusb functions, prefixed with "usbi_". Documentation for these functions |
| 50 can be found in the .c files where they are implemented. |
| 51 |
| 52 You probably want to skim over *all* the documentation before starting your |
| 53 implementation. For example, you probably need to allocate and store private |
| 54 OS-specific data for device handles, but the documentation for the mechanism |
| 55 for doing so is probably not the first thing you will see. |
| 56 |
| 57 The Linux backend acts as a good example - view it as a reference |
| 58 implementation which you should try to match the behaviour of. |
| 59 |
| 60 |
| 61 Getting started |
| 62 =============== |
| 63 |
| 64 1. Modify configure.ac to detect your platform appropriately (see the OS_LINUX |
| 65 stuff for an example). |
| 66 |
| 67 2. Implement your backend in the libusb/os/ directory, modifying |
| 68 libusb/os/Makefile.am appropriately. |
| 69 |
| 70 3. Add preprocessor logic to the top of libusb/core.c to statically assign the |
| 71 right usbi_backend for your platform. |
| 72 |
| 73 4. Produce and test your implementation. |
| 74 |
| 75 5. Send your implementation to libusb-devel mailing list. |
| 76 |
| 77 |
| 78 Implementation difficulties? Questions? |
| 79 ======================================= |
| 80 |
| 81 If you encounter difficulties porting libusb to your platform, please raise |
| 82 these issues on the libusb-devel mailing list. Where possible and sensible, I |
| 83 am interested in solving problems preventing libusb from operating on other |
| 84 platforms. |
| 85 |
| 86 The libusb-devel mailing list is also a good place to ask questions and |
| 87 make suggestions about the internal API. Hopefully we can produce some |
| 88 better documentation based on your questions and other input. |
| 89 |
| 90 You are encouraged to get involved in the process; if the library needs |
| 91 some infrastructure additions/modifications to better support your platform, |
| 92 you are encouraged to make such changes (in cleanly distinct patch |
| 93 submissions). Even if you do not make such changes yourself, please do raise |
| 94 the issues on the mailing list at the very minimum. |
| 95 |
OLD | NEW |