linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rhoads, Rob" <rob.rhoads@intel.com>
To: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Cc: "Rhoads, Rob" <rob.rhoads@intel.com>
Subject: [ANNOUNCE] Linux Hardened Device Drivers Project
Date: Fri, 20 Sep 2002 17:26:47 -0700	[thread overview]
Message-ID: <D9223EB959A5D511A98F00508B68C20C0A53899F@orsmsx108.jf.intel.com> (raw)


Project Announcement:
--------------------
We've started a new project on sourceforge.net w/ focus 
on hardening Linux device drivers for highly available 
systems. This project is being worked on with folks from 
OSDL's CGL and DCL projects as well.

Initially we've created a specification, a few kernel modules
that implement a set of driver programming interfaces, and
a sample device driver that demonstrates those interfaces.

We are actively soliciting involvement with others in the 
Linux developer community. We need your help to make this 
project relevant and useful. 

Below I've included an overview of the hardened driver project. 
By no means is this complete or final. It's just our initial
attempt at defining what is meant by the term hardened driver
and the areas we want to focus on.

For additional info, please checkout the links at the bottom 
of this message and the Hardened Drivers web site at 
http://hardeneddrivers.sf.net.


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. A critical element in creating Highly Available (HA)
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 (e.g. allow device fail-over), 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 is to provide an environment 
in which hardware and software failures are transparent to 
the applications using their services, where possible. The 
way to effectively achieve this goal is to analyze a 
driver's software design and implement appropriate changes
to improve stability, reliability and availability, and 
to provide instrumentation for management middleware.

We believe that 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 failure.

To minimize instability contributed by device drivers and to 
enhance the availability of HA systems, we've attempted to 
define a set of requirements that a device driver should 
adhere to in order to be considered a hardened driver. We 
then define different hardening traits and the required 
programming interfaces to support these hardening traits.

We've identified four areas in which drivers can be hardened:
o Hardening with code robustness
o Hardening with event logging
o Hardening with diagnostics
o Hardening with resource monitoring and statistics

We've also identified some key areas we feel are most critical
to overall system stability and plan to focus initial hardening 
efforts on drivers for network interface cards, physical storage, 
and logical storage.

Project Links:
-------------
o The Driver Hardening website:  
  http://hardeneddrivers.sourceforge.net

o The SourceForge project related info:
  http://sourceforge.net/projects/hardeneddrivers

o Hardened Drivers Mailing List Info (subscribe here):
  http://lists.sourceforge.net/mailman/listinfo/hardeneddrivers-discuss


+=+=+
Rob Rhoads                     mailto:rob.rhoads@intel.com
Staff Software Engineer        office: 503-677-5498
Telecom Software Platforms
Intel Communications Group

This email message solely contains my own personal views, and not
necessarily those of my employer.


             reply	other threads:[~2002-09-21  0:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-21  0:26 Rhoads, Rob [this message]
2002-09-21  0:54 ` [ANNOUNCE] Linux [add-more-silly-APIs] Device Drivers Project Jeff Garzik
2002-09-21  1:06 ` [ANNOUNCE] Linux Hardened " Andre Hedrick
2002-09-21 10:41   ` Bernd Eckenfels
2002-09-21 11:20     ` Russell King
2002-09-21  1:40 ` Greg KH
2002-09-21  5:34   ` my review of the Device Driver Hardening Design Spec Greg KH
2002-09-21 15:21     ` Martin J. Bligh
2002-09-23  6:13 ` [ANNOUNCE] Linux Hardened Device Drivers Project Randy.Dunlap
2002-09-23 12:31 ` Lars Marowsky-Bree
2002-09-23 22:38 ` Rhoads, Rob
2002-09-24  0:08   ` Greg KH
2002-09-24 17:12   ` Greg KH
     [not found] <mailman.1032570840.22498.linux-kernel2news@redhat.com>
2002-09-21  2:14 ` Pete Zaitcev
2002-09-21  3:30   ` Andre Hedrick
2002-09-21  3:00 Rhoads, Rob
2002-09-21  3:47 ` Andre Hedrick
2002-09-21  4:09 ` Mark Veltzer
2002-09-23 13:23 Manfred Spraul
2002-09-24 19:30 Rhoads, Rob
2002-09-24 19:55 ` Greg KH
2002-09-24 21:46 Rhoads, Rob
2002-09-24 23:07 ` Greg KH
2002-09-24 23:29 Rhoads, Rob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D9223EB959A5D511A98F00508B68C20C0A53899F@orsmsx108.jf.intel.com \
    --to=rob.rhoads@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).