From: Pete B. <pb...@gm...> - 2009-12-23 20:20:47
|
Hello all, The Windows implementation of libusb 1.0 is progressing nicely (we now have async control transfers), and before moving to data transfers, since I think I have now sorted a libusb compatible poll & pipe emulation layer for Windows, I thought I'd check with you if the resulting proposed changes to the core files are acceptable. The new custom poll & pipe layer for Windows is now totally independent from any external code or libraries. It relies on the Windows overlapped implementation for asynchronous transfers (http://msdn.microsoft.com/en-us/library/aa365683%28VS.85%29.aspx) and bundles an Overlapped and a Windows Handle into a structure that also contains a regular system fd. Now, because we need poll to work both with USB I/O overlapped as well as the libusb control pipe overlapped, I had to define a set of custom I/O functions for the pipe handling. In short, to be able to use the control pipe with our custom poll, pipe(), read() and close() have to be redefined (write was redefined as well, although we could probably do away with it). These functions should be generic enough to be used with other handles than a pipe, as long as they have been opened for overlapped. As trying to #undef read/write/close to enforce our custom versions on Windows would be ill advised, I am proposing to change the core files, so that all related system calls for the control pipe are clearly flagged for polling intention, and so that they point to the custom functions on Windows. This basically means modifying the following in the parts of the code that deal with the control pipe: read() -> read_for_poll() write() -> write_for_poll() close() -> close_for_poll() pipe() -> pipe_for_poll() NB: we don't have an open_for_poll because there is no need for one ATM, but this could easily be created. Also the pipe_for_poll is not entirely necessary, since there's no conflicting pipe() on Windows, but is there to clarify the pipe's purpose. Then, because these custom functions are only necessary on Windows, the following would be needed in the headers: #ifdef OS_WINDOWS #include <windows.h> #include "os/windows_compat.h" #else #include <poll.h> #define write_for_poll write #define read_for_poll read #define close_for_poll close #define pipe_for_poll pipe #endif An example of the diff this would incur on core.c and io.c can be found here: http://code.google.com/p/libusb-winusb-wip/source/diff?spec=svn29&r=29&format=side&path=/trunk/libusb/core.c http://code.google.com/p/libusb-winusb-wip/source/diff?spec=svn29&r=29&format=side&path=/trunk/libusb/io.c I believe the changes are fairly lightweight, and should not have any impact on existing platforms, but if you think there is a potential problem, let me know. For more details about the poll implementation, please have a look at the windows_compat source: http://code.google.com/p/libusb-winusb-wip/source/browse/trunk/libusb/os/windows_compat.c and http://code.google.com/p/libusb-winusb-wip/source/browse/trunk/libusb/os/windows_compat.h Regards, /Pete |