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 |