 |
Jungo WinDriver
Official Documentation
|
|
Jungo WinDriver
Official Documentation
|
This chapter provides you with a general introduction to device drivers and takes you through the structural elements of a device driver.
⚠ Attention
When using WinDriver you do not need to familiarize yourself with the internal workings of driver development. As explained in 1.1. Introduction, WinDriver enables you to communicate with your hardware and develop a driver for your device from the user mode, using only WinDriver's simple APIs, without any need for driver or kernel development knowledge.
Device drivers are the software segments that provide an interface between the operating system and the specific hardware devices — such as terminals, disks, tape drives, video cards,and network media. The device driver brings the device into and out of service, sets hardware parameters in the device, transmits data from the kernel to the device, receives data from the device and passes it back to the kernel, and handles device errors.
A driver acts like a translator between the device and programs that use the device. Each device has its own set of specialized commands that only its driver knows. In contrast, most programs access devices by using generic commands. The driver, therefore, accepts generic commands from a program and then translates them into specialized commands for the device.
There are numerous driver types, differing in their functionality. This subsection briefly describes three of the most common driver types.
Monolithic drivers are device drivers that embody all the functionality needed to support a hardware device. A monolithic driver is accessed by one or more user applications, and directly drives a hardware device. The driver communicates with the application through I/O control commands (IOCTLs) and drives the hardware using calls to the different WDK, ETK, DDI/DKI functions.
Monolithic drivers are supported in all operating systems including all Windows platforms and all Unix platforms.
Layered drivers are device drivers that are part of a stack of device drivers that together process an I/O request. An example of a layered driver is a driver that intercepts calls to the disk and encrypts/decrypts all data being transferred to/from the disk. In this example, a driver would be hooked on to the top of the existing driver and would only do the encryption/decryption.
Layered drivers are sometimes also known as filter drivers, and are supported in all operating systems including all Windows platforms and all Unix platforms.
Miniport driver is an add-on to a class driver that supports miniport drivers. It is used so the miniport driver does not have to implement all of the functions required of a driver for that class. The class driver provides the basic class functionality for the miniport driver. A class driver is a driver that supports a group of devices of common functionality, such as all HID devices or all network devices.
Miniport drivers are also called miniclass drivers or minidrivers, and are supported in the Windows 7 and higher operating systems.
Windows 7 and higher operating systems provide several driver classes (called ports) that handle the common functionality of their class. It is then up to the user to add only the functionality that has to do with the inner workings of the specific hardware. The NDIS miniport driver is one example of such a driver. The NDIS miniport framework is used to create network drivers that hook up to Windows's communication stacks, and are therefore accessible to common communication calls used by applications. The Windows kernel provides drivers for the various communication stacks and other code that is common to communication cards. Due to the NDIS framework, the network card developer does not have to write all of this code, only the code that is specific to the network card he is developing.
Windows Driver Model (WDM) drivers are kernel-mode drivers within the Windows operating systems. WDM works by channeling some of the work of the device driver into portions of the code that are integrated into the operating system. These portions of code handle all of the low-level buffer management, including DMA and Plug-and-Play (Pnp) device enumeration. WDM drivers are PnP drivers that support power management protocols, and include monolithic drivers, layered drivers and miniport drivers.
The Windows Driver Foundation (WDF) is a wrapper around Microsoft Windows Driver Model (WDM) interfaces and is the preferred way to implement Windows drivers today. WDF is a set of Microsoft tools and libraries that aid in the creation of device drivers for Windows. It abstracts away much of the complexity of writing Windows drivers.
⚠ Attention
From version 5.2.0 to 14.1.1 WinDriver was a WDM driver. From version 14.1.1 WinDriver is a full WDF driver.
In the classic Unix driver model, devices belong to one of three categories: character (char) devices, block devices and network devices. Drivers that implement these devices are correspondingly known as char drivers, block drivers or network drivers. Under Unix, drivers are code units linked into the kernel that run in privileged kernel mode. Generally, driver code runs on behalf of a user-mode application. Access to Unix drivers from user-mode applications is provided via the file system. In other words, devices appear to the applications as special device files that can be opened.
Unix device drivers are either layered or monolithic drivers. A monolithic driver can be perceived as a one-layer layered driver.
Linux device drivers are based on the classic Unix device driver model. In addition, Linux introduces some new characteristics.
Under Linux, a block device can be accessed like a character device, as in Unix, but also has a block-oriented interface that is invisible to the user or application.
Traditionally, under Unix, device drivers are linked with the kernel, and the system is brought down and restarted after installing a new driver. Linux introduces the concept of a dynamically loadable driver called a module. Linux modules can be loaded or removed dynamically without requiring the system to be shut down. A Linux driver can be written so that it is statically linked or written in a modular form that allows it to be dynamically loaded. This makes Linux memory usage very efficient because modules can be written to probe for their own hardware and unload themselves if they cannot find the hardware they are looking for.
Like Unix device drivers, Linux device drivers are either layered or monolithic drivers.
Every device driver must have one main entry point, like the main() function in a C console application. This entry point is called DriverEntry() in Windows and init_module() in Linux. When the operating system loads the device driver, this driver entry procedure is called.
There is some global initialization that every driver needs to perform only once when it is loaded for the first time. This global initialization is the responsibility of the DriverEntry()/init_module() routine. The entry function also registers which driver callbacks will be called by the operating system. These driver callbacks are operating system requests for services from the driver. In Windows, these callbacks are called dispatch routines, and in Linux they are called file operations. Each registered callback is called by the operating system as a result of some criteria, such as disconnection of hardware, for example.
Operating systems differ in the ways they associate a device with a specific driver.
In Windows, the hardware-driver association is performed via an INF file, which registers the device to work with the driver. This association is performed before the DriverEntry() routine is called. The operating system recognizes the device, checks its database to identify which INF file is associated with the device, and according to the INF file, calls the driver's entry point.
In Linux, the hardware-driver association is defined in the driver's init_module() routine. This routine includes a callback that indicates which hardware the driver is designated to handle. The operating system calls the driver's entry point, based on the definition in the code.
Communication between a user-mode application and the driver that drives the hardware, is implemented differently for each operating system, using the custom OS Application Programming Interfaces (APIs).
On Windows, and Linux, the application can use the OS file-access API to open a handle to the driver (e.g., using the Windows CreateFile() function or using the Linux open() function), and then read and write from/to the device by passing the handle to the relevant OS file-access functions (e.g., the Windows ReadFile() and WriteFile() functions, or the Linux read() and write() functions).
The application sends requests to the driver via I/O control (IOCTL) calls, using the custom OS APIs provided for this purpose (e.g., the Windows DeviceIoControl() function, or the Linux ioctl() function).
The data passed between the driver and the application via the IOCTL calls is encapsulated using custom OS mechanisms. For example, on Windows the data is passed via an I/O Request Packet (IRP) structure, and is encapsulated by the I/O Manager.
1.11.0