Driver Model

Draft Version

 

 

 

 

 

 

Goals

 

  1. Managing IO Space
  2. Distributing Interrupts
  3. Abstracting PIC/APIC

 

Design

 

 

 

Issues

  1. Uniform Naming
  2. Performance
  3. Generic Structure for message passing

Example

 

The picture illustrates how the communication between application/driver/kernel will happen during an IO request. The following picture is drawn for system synchronous READ call from an application.

 

 

  1. The application makes a system call(read()) which will transfer the control from user mode to kernel mode. The kernel passes read message (IPC) to the FS task and then kernel puts this thread in sleep mode waiting for FS to wakeup.

 

  1. The FS task/thread will be sleeping for a message in its mail box. If there is any message posted it will be woken up and will be running in high priority. The FS will post IO read to IDE and go for sleep.

 

  1. The IDE driver thread reads data from harddisk and woke up the FS.

 

  1. The FS processes the data and may call the driver again. After finishing its work FS wakes up the application.

 

Managing IO Space

 

For performance reasons, there will be little control over IO space. The IO flag in control registers should set to ring 1. This means only ring 0 and ring1 processes can access IO space. Since only kernel will be in ring 0 and drivers in ring 1, applications can’t access the IO space.

 

The kernel should not worry about managing/sharing IO space between drivers. It will be overhead. Kernel will manage a sparse tree for managing IO Space. A driver can allocate IO Space from kernel. If a driver allocated a memory then that range can’t be allocated by other drivers. If other drivers try to allocate that range then that system call will fail. However there wont any checking to control drivers to access only allocated space.

 

 

The above picture explains all the drivers has full access to IO Space, however it should access only the allocated IO Space.

 

Provision should be added to share IO space between to drivers.

 

Managing Interrupts

 

Kernel setups PIC/APIC to receive interrupts; the default interrupt hander is a kernel stub function. These stub function will call the real driver’s interrupt handler if one registered.

 

Drivers should register an entry point for every interrupt request it is expecting and it should give priority for the interrupt also. The driver is only responsible for completing IRQ for the device. It should not send EOI to PIC. Kernel will send EOI to the PIC before calling the registered handler. In this way, interrupts can be distributed.

 

The above picture explains, only kernel entry points can registered in IDT and PIC/APIC are programmed only by kernel. Drivers even don’t send EOI to PIC.

 

When an interrupt occurs, the currently running thread enters into kernel mode (kernel interrupt handlers) and then checks whether any driver registered any handler for the raised IRQ, if no handler is register, the interrupt is ignored. If a handler is registered then the handler is waked up and a priority boost will be given to the driver thread.

 

Here there should be a provision should to switch to the driver and run the handler without full context switch. Because full context switch might take longer time. To achieve partially this, interrupt handlers code should not made pageable.

 

Dependency

Boot loader:

Boot loader should capable of loading certain drivers during the boot of kernel. For example- boot loader should load Storage and FS drivers during boot.

 

MM:

  1. Should provide contiguous physical memory
  2. Should provide option to lock the memory
  3. Should provide mechanism to share memory between tasks
  4. Should provide option to not caching a part of memory

 

IPC:

  1. Message passing between applications

PM:

  1. Sleep for a particular object
  2. Sleep for multiple object