Communication with the USB stack and client applications
At this point of the process in writing a Linux USB Driver, you'd need to know how to write a file_operations structure, and what to
populate the open(), close(), read(), and write() callbacks with.
However, QNX doesn't provide a filesystem as part of the kernel. Thus, there is no guarantee that it will be present and running on the
system (assuming this driver is not made for a specific system's
use-case).
Because of this, io-usb isn't made with the expectation that
resources are accessed at file locations. The driver itself
needs to determine how to make its resources available to client
applications. This driver doesn't cover any specific way to do
this, as information on this exists already, but there are some options to do so:
To provide similar access as in Linux, consider making your driver a device resource manager. This is the most common way of providing access.
If your client applications all have GUIs and use QNX's Screen API, consider using a Screen input provider and push events through Screen to be accessed via the events system.
If communication is time-critical, consider reading up on other methods of interprocess communication (IPC) on QNX. Specifically, in QNX, the kernel handles message passing and has some features involving the scheduler that allow for much faster communication times.
The remainder of this chapter covers submitting URBs to the USB Stack for processing and other steps required for I/O.