DDE/DDEKit: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
[[Category:DDE]] | |||
== Overview == | == Overview == | ||
Revision as of 16:55, 30 January 2012
Overview
Device drivers are an essential element in every operating system, because without them no interaction with the external world is possible. Because of the huge range of available devices, implementing L4 device drivers for even the most common devices on the market would be a tedious job. To circumvent this problem and support a wide range of devices on L4, we designed DDE, the Device Driver Environment. Aim of this project is to provide legacy device driver interfaces, so that the large amount of readily available device drivers for other operating systems (such as Linux and BSD) can be reused on L4 with few effort.
DDE consists of three layers:
- DDEKit is a glue layer between the L4Re and the higher device driver layers.
- DDE<someOS> implement OS-specific environments for every supported OS.
- native device drivers are not modified and simply linked against the DDE/DDEKit libraries and extended with a little server code in order to export their interface to other L4 applications.
DDEKit
Even though running inside different operating system environments, drivers usually make use of a certain functionality. DDEKit provides such functionality and therefore relies on L4Re services being available. The mechanisms implemented by DDEKit are:
- Device resource management
- Interrupts
- I/O ports (x86-specific)
- I/O memory
- Access to the PCI config space
- Memory Management
- Memory allocation
- Mapping of virtual to physical addresses
- Threads
- Management of threads
- Synchronization mechanisms
- Locks
- Semaphores
- Condition variables
- Thread-local storage
- Utilities
- Initcalls
- printf(), panic()
The purpose of DDEKit is to provide a common interface to this functionality, so that implementing DDEs for different legacy operating systems becomes easier due to code reuse.
OS-Specific Environments
Based on DDEKit, it is possible to build OS-specific device driver environments and thus reuse drivers from a legacy OS on top of L4. Additionally, it is even possible, to use DDEs to reuse complete software stacks (such as an IP stack).
DDE/Linux2.6
DDE/Linux2.6 is an environment for Linux 2.6 device drivers on L4. Basically, it is a set of libraries implementing interfaces to certain subsystems of the Linux kernel, so that the programmer may chose which parts of the kernel are needed for reusing a special device driver (e.g., network drivers don't need block layer functionality). Currently, the following subsystems are available:
- Core (libdde_linux26) provides functions that are essential to (nearly) all drivers. This includes for instance memory management, I/O resource management, workqueues, softirqs, and timers.
- Net (libdde_linux26_net) provides network-related functions such as management of socket buffers.
- Block (libdde_linux26_block) provides functions related to the Linux block layer such as a file system buffer abstraction, I/O schedulers, block I/O descriptors (BIOs).
- USB (libdde_linux26_usb) implements USB-related functions which enable drivers to use the Linux USB core as well as USB host controllers. This is work in progress.
- Sound (libdde_linux26_sound) includes the Linux sound core which is the base for implementing sound subsystems such as OSS and Alsa. This is work in progress.
Work USB and Sound support libraries is ongoing.
DDE/FBSD
Applications using DDE/DDEKit
Flips - the Flexible IP Stack
Flips is a port of the Linux 2.4 IP stack to L4 using DDE. Network devices are accessed through the ORe ethernet switch.
ORe - a software ethernet switch
ORe is a software ethernet switch. Clients are assigned a dedicated MAC and then the ethernet interface is multiplexed for all of them. Incoming packets are routed to the correct client, sending outgoing packets is serialized between clients.
Windhoek - the L4 block device server
Windhoek is a block device server. It currently uses the deprecated Linux IDE code to driver IDE hard disks. Porting it to use the newer libATA is on the TODO list, so that it will finally also support SCSI and USB storage devices through a common interface.