| 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 | 
|---|