[cgl_discussion] Invitation for Participation on the Hardened Drivers Project
rob.rhoads at intel.com
Thu Sep 12 18:25:52 PDT 2002
This is an invitation to all engineers involved with OSDL
Carrier Grade Linux, that have an interest in device drivers
and hardened drivers in particular, to participate in the Open
Source Hardened Driver Project hosted on SourceForge.
The immediate goal for CGL members is to formally review the current
Harden Device Driver draft specification. I would like to do this in
the open and invite you to participate via the Hardened Driver
mailing list on SourceForge. I think it is critical for the success
of this project to seek input from Linux kernel developer community
and I plan on publicizing this project on the Linux Kernel mailing
list in the immediate future. Your input and feedback would be
greatly appreciated on this project.
If you are interested please sign up on the Hardened Driver mailing
list (see links below) and grab a copy of the Hardened Driver spec
on the web page. I will be sending out, on that mailing list, more
info and a proposed review schedule for the document.
On the project page you will also find links to related projects and
source code for the kernel header files, defined within the
specification and a sample driver which use those APIs.
On this bottom of this e-mail you will also find the Hardened Driver
description/overview that appears in the CGL Arch Spec.
o The Driver Hardening website:
o Hardened Drivers (Draft) Specification:
o The SourceForge project related info:
o Hardened Drivers Mailing List Info (subscribe here):
Hardened Driver Project Overview:
Device drivers have traditionally been a significant source of
software faults. For this reason, they are of key concern in
improving the availability and stability of the operating system.
Their higher rate of faults can be explained in part by the fact
that drivers run in kernel space, but because they are only used
with specific hardware, they can never receive the same level of
field-testing as the kernel itself. A critical element in creating
an OSDL CGL environment is to reduce the likelihood of faults
in key drivers, a methodology called driver hardening.
A device driver is typically implemented with emphasis on the
proper operation of the hardware. Attention to how it will
function in the event of hardware faults is often minimal.
Hardened drivers, on the other hand, are designed with the
assumption that the underlying hardware that they control will
fail. They need to respond to such failures by handling faults
gracefully, limiting the impact on the overall system.
Hardened device drivers must continue to operate when the
hardware has failed, or is not present, and must not allow
the propagation of corrupt data from a failed device to other
components of the system.
Hardened device drivers must also be active participants in
the recovery of detected faults, by locally recovering them
or by reporting them to higher-level system management software
that subsequently instructs the driver to take a specific action.
The goal of a hardened driver in OSDL CGL is to provide an
environment in which hardware and software failures are
transparent to the applications using their services. The
way to effectively achieve this goal is for the driver
developer to analyze a driver's software design and implement
appropriate changes to improve stability, reliability and
availability, and to provide instrumentation for management
Improving driver stability and reliability includes such measures
as ensuring that all wait loops are limited with a timeout,
validating input and output data and structuring the driver to
anticipate hardware errors. Improving availability includes adding
support for device hot swapping and validating the driver with fault
injection. Instrumentation for management middleware includes
functions such as reporting of statistical indicators and logging of
pertinent events to enable postmortem analysis in the event of a
To minimize instability contributed by device drivers and to further
enhance the availability of OSDL CGL based systems, OSDL CGL defines
requirements for a device driver to be considered a hardened driver.
OSDL CGL defines different device driver hardening traits and the
required programming interfaces to support these hardening traits.
A driver can support four hardening traits:
· Hardening with code robustness
· Hardening with event logging
· Hardening with diagnostics
· Hardening with resource monitoring and statistics
Device drivers for network interface cards, physical storage, and
logical storage should be hardened for use with OSDL CGL
Rob Rhoads mailto:rob.rhoads at intel.com
Staff Software Engineer office: 503-677-5498
This email message solely contains my own personal views, and not
necessarily those of my employer.
More information about the cgl_discussion