Device Drivers

Modeling Device Driver Effects in Real-Time Schedulability Analysis: Study of a Network Driver

ByLewandowski, M. Stanovich, M.J. Baker, T.P.

Gopalan, K. An-I Wang Dept. of Computer. Sci., Florida State Univ.,

Tallahassee, FL;

Presentation overview

Introduction to device drivers

Design of device drivers

Device drivers working

Device drivers in real time

Scheduling process

Case studies

References

What is a device driver?

A device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device.

Device drivers are integral components of operating systems.

Why a device driver ?

A device driver simplifies programming by acting as an abstraction layer between a hardware device and the applications or operating systems that use it

The higher-level application code can be written independently of whatever specific hardware device it will ultimately control, as it can interface with it in a standard way, regardless of the underlying hardware.

The device-driver accepts the generic high-level commands and breaks them into a series of low-level device-specific commands as required by the device being driven.

Device Drivers can provide a level of security as they can run in kernel-mode, thereby protecting the operating system from applications running in user-mode.

Why a device driver ? .. [contd.]

Ring 0

Kernel

Ring 1Ring 2

Ring 3

Device Drivers

Device Drivers

Applications

Lest Privileged

Most Privileged

Privilege rings available

Device Driver design

Device Driver Design …[Contd.]

•System initialization•System calls from user processes •User-level requests•Device interrupts•Bus reset

How Drivers are accessed ?

Disadvantages of device drivers in real time

Real-time systems need to guarantee that certain workloads can be completed within specified time constraints.

Device drivers have traditionally been a weak spot of most operating systems, especially in terms of accounting and control of the resources consumed by these software components.

Each device driver’s code may run in multiple (possibly concurrent) execution contexts which makes the resource accounting difficult, if not impossible.

Device drivers are scheduled in a hierarchy of ad hoc mechanisms, namely hard interrupt service routines (ISR), softirqs, and process or thread contexts, in decreasing order of execution priorities.

Every device driver interrupt must be handled in real time, i.e. as and when the driver routine is called.

For this there has to be a Schedulability mechanism to do it in real time.

We discuss here the Demand based Schedulability and its analysis on device drivers.

There are two approaches to DBS analysis i) Measure of computational demand ii)Ad-hoc mechanisms to schedule a-periodic tasks

How to overcome it?

What is a demand analysis ?

A job is a schedulable component of computational work with a release time, a deadline, and an execution time.

The computational demand of a job J in a given time interval (a, b) for a given schedule, denoted by demand J(a, b), is defined to be the actual amount of processor time consumed by that job within the interval.

Every job will be completed on time as long as the sum of its own execution time and the interference caused by the execution of other higher priority jobs within the same time window during which the job must be completed add up to no more than the length of the window.

A job Jk released at time rk with deadline rk +dk and execution time ek will be completed by its deadline if ek + ∑i<k demandJi (rk, rk + dk) ≤ dk

What is a demand analysis ?

A task is an abstraction for a collection of possible sequences of jobs.

The notions of computational demand and interference extend naturally to tasks. The function demandmax

Ti(∆) is the maximum of combined demands of all the jobs of Ti in every time interval of length , taken over all possible job sequences of Ti.

That is if S is the collection of all possible job sequences of Ti then demandmax

Ti(∆) = def max S€S ,t>0∑J € S demandJ (t − ∆ , t)

Case Studies

A network interface controller (NIC), is a computer hardware component designed to allow computers to communicate over a computer network.

It is both an OSI layer 1 (physical layer) and layer 2 (data link layer) device, as it provides physical access to a networking medium and provides a low-level addressing system through the use of MAC addresses.

It allows users to connect to each other either by using cables or wirelessly.

Network Interface Controller (NIC),

Network interface device drivers present the biggest challenge for modeling and Schedulability analysis.

The Linux e1000 driver leaves the hardware interrupts for incoming packets disabled as long as there are queued received packets that have not been processed. The device interrupt is only re-enabled when the server thread has polled.

The device-driven workload of the e1000 driver can be viewed as two device-driven tasks: i)Input Processing which includes dequeuing packets that the device has previously received and copied directly into system memory. ii)Output processing, which includes dequeuing packets already sent and the enqueueing of more packets to send.

The Linux e1000 Driver

The hardware preempts the currently executing thread

The driver’s ISR does the minimumamount of work necessary

The softirq handler does the restof the driver’s work

The Linux e1000 Driver

Thread context

Level 3Softriq

Level 2Driver ISR

Level 1Generic ISR

Interrupt Context

www.en.wikipedia.org

www.dlc.sun.com

www.tjdl.uh.edu/articles/1/lectures/tables.cfm

www.macsoft-firmware.com

Modeling device driver effects in real-time schedulability analysis:Study of a network driver (IEEE paper)

Papers

Websites

References

Linux Device Drivers

Books

By Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman

Thank you

Questions….????