public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: "Rhoads, Rob" <rob.rhoads@intel.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] Linux [add-more-silly-APIs] Device Drivers Project
Date: Fri, 20 Sep 2002 20:54:47 -0400	[thread overview]
Message-ID: <3D8BC357.3080609@mandrakesoft.com> (raw)
In-Reply-To: D9223EB959A5D511A98F00508B68C20C0A53899F@orsmsx108.jf.intel.com

Rhoads, Rob wrote:
> 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.

[...]
> 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. 
[...]
> 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.


Sigh.

While the goal is certainly good and true, the implementation really stinks.

You simply cannot "harden" drivers by adding additional statistics nor 
by printing diagnostic messages via printk().  Further, centralizing 
--domain-specific-- diagnostics and statistics is just plain moving in 
the wrong direction.

Hardening drivers is a __human__ problem.  People use existing APIs and 
fuck up, thus creating bugs.  You are attempting to paper it over with 
buzzword-compliant features, but not actually addressing the real 
problem.  Adding silly APIs does not fix this.  You can't avoid getting 
down and dirty and actually fixing the drivers, and fixing up the 
_existing_ APIs so that humans create fewer bugs.

I fully support hardening, and "carrier grade linux."  This just ain't 
the way to do it.

[no offense intended.  if you think my comments harsh, wait until Al 
Viro sees your sample driver...]

	Jeff




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

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-21  0:26 [ANNOUNCE] Linux Hardened Device Drivers Project Rhoads, Rob
2002-09-21  0:54 ` Jeff Garzik [this message]
2002-09-21  1:06 ` 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

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=3D8BC357.3080609@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rob.rhoads@intel.com \
    /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