Device Drivers Modeling Device Driver Effects in Real-Time Schedulability Analysis: Study of a Network Driver By Lewandowski, 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

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.

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 1 Ring 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 ?

System initialization

System calls from user processes

User-level requests

Device interrupts

Bus reset

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.

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?

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

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 J k released at time r k with deadline r k +d k and execution time e k will be completed by its deadline if e k + ∑ i<k demand Ji (r k , r k + d k ) ≤ d k

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 J k released at time r k with deadline r k +d k and execution time e k

will be completed by its deadline if

e k + ∑ i<k demand Ji (r k , r k + d k ) ≤ d k

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 demand max Ti (∆) is the maximum of combined demands of all the jobs of T i in every time interval of length , taken over all possible job sequences of T i . That is if S is the collection of all possible job sequences of T i then demand max Ti (∆) = def max S€S ,t>0∑ J € S demand J (t − ∆ , t)

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 demand max Ti (∆)

is the maximum of combined demands of all the jobs of T i in every

time interval of length , taken over all possible job sequences of T i .

That is if S is the collection of all possible job sequences of T i then

demand max Ti (∆) = def max S€S ,t>0∑ J € S demand J (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

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 hardware preempts the currently executing thread The driver’s ISR does the minimum amount of work necessary The softirq handler does the rest of the driver’s work The Linux e1000 Driver Thread context Level 3 Softriq Level 2 Driver ISR Level 1 Generic 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….????