This shows you the differences between two versions of the page.
— |
developersguide:overviewofminixdrivers [2015/04/24 23:11] (current) jeanbaptisteboric created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Overview of Minix 3 drivers ====== | ||
+ | |||
+ | Drivers are software components used to manage hardware peripherals. In Minix, drivers are implemented as user-mode processes, and they use the micro-kernel to manage the hardware through it. | ||
+ | |||
+ | The drivers source code are located under the minix/drivers/ directory in the Minix source tree. The binary executables are located under the /service/ directory. | ||
+ | |||
+ | ===== Unix device drivers ===== | ||
+ | |||
+ | Like Unix and Unix-likes operating systems, Minix divides drivers in two categories, character and block devices, and they can be accessed just like regular files on the file system by the user-land through device nodes. | ||
+ | |||
+ | Driver types differ essentially in what services and operations they support. | ||
+ | |||
+ | ==== Block device ==== | ||
+ | |||
+ | A block device treats data in chunks called blocks, each block being composed of a constant number of bytes. Block devices support the seek operation, which allows access to any block at any moment. | ||
+ | |||
+ | Block devices generally represents storage media, such as hard disk and CD drives. | ||
+ | |||
+ | ==== Character device ==== | ||
+ | |||
+ | A character device treats data as a stream of bytes. Character devices do not support the seek operation and so do not have to actually represent a storage media or even a real hardware peripheral. | ||
+ | |||
+ | Character devices represents everything block devices cannot, from real hardware components (printers, serial ports) to virtual, abstract entities (TTY, random number generators...). | ||
+ | |||
+ | ===== Drivers implementation ===== | ||
+ | |||
+ | Minix drivers are processes, but unlike other processes they have permission to access their I/O ports through the micro-kernel. | ||
+ | |||
+ | ==== Low-level protocols ==== | ||
+ | |||
+ | Drivers interact closely with three important components and so have specialized low-level protocols for each of the virtual file server, the reincarnation server and the micro-kernel. Like all processes, drivers communicate with message passing, memory grants and system calls so those protocols are defined in those terms. | ||
+ | |||
+ | ==== High-level abstraction libraries ==== | ||
+ | |||
+ | Libraries were created to provide driver developers with a higher-level abstraction interface. Besides easing development, those libraries shield the drivers from low-level protocols changes to a certain extent. | ||
+ | |||
+ | The corresponding driver abstraction libraries are : | ||
+ | |||
+ | * blockdriver : for block-oriented drivers, | ||
+ | * chardriver : for generic character-oriented drivers, | ||
+ | * inputdriver : for drivers communicating with the input server, | ||
+ | * netdriver : for network device drivers. | ||