Thursday, March 8, 2007

Developing Drivers from Windows

Download Free ScreenSavers and Wallpapers! - http://offr.biz/HLSCR300468KXRFJFT




Definition Device Driver

A device driver, often called a driver for short, is a computer program that enables another program, typically, an operating system (e.g., Windows, Linux) to interact with a hardware device. A driver is essentially an instruction manual that provides the operating system with the information on how to control and communicate with a particular piece of hardware.





Windows 2000 Driver Design Goals

  • Portability
    • The driver program should be compatible across all platforms. So it is must not be written in assembly language coding since instruction sets changes from processor to processors. Coding in C would be good idea since it can be recompiled and run on any platform. But care should be taken as to, no library function are used. Since those library function may not be available on another platform.
  • Configurability
  • Always pre-emptive and interruptive
    • Pre-emptive scheduling means if a higher priority process arrives then the processor sends the process, which is in execution to the wait state and executes the higher priority process. This type of scheduling is an effective way to maximize average performance.
    • Two schemes are used here
      • The Kernel-defined run-time priority scheme for threads
      • The Kernel-defined interrupt request level (IRQL)
        • Priority order of IRQL
          • Software Interrupts - low priority
          • Decvice drivers - higher priority
          • System-critical such as system clock or bus-error interrupts - highest priority.
  • Multiprocessor-safe on multiprocessor platforms
    • In a multiprocessor environment a process will check each processor to execute its process. Care should be taken as to, that the process should not be executed in two processors.
  • Object-based
    • If we design our driver program as separate routines or objects then modifying the driver can be very useful in future implementations.
  • Packet-driven I/O with reusable I/O request packets
    • I/O requests can be small or big. Sending then as such would result in tremendous overhead. So as such we group them into packets or split large packets and send them across to various destinations.
  • Support for asynchronous I/O
    • Asynchronous means the process does not wait for the request to be completed. Instead it carries on with the next set of instruction.
    • This is very good time saving mechanism.

1 comment: