public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Bernd Eckenfels <ecki-news2002-09@lina.inka.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] Linux Hardened Device Drivers Project
Date: Sat, 21 Sep 2002 12:20:41 +0100	[thread overview]
Message-ID: <20020921122041.A27150@flint.arm.linux.org.uk> (raw)
In-Reply-To: <E17shi3-00083J-00@sites.inka.de>; from ecki-news2002-09@lina.inka.de on Sat, Sep 21, 2002 at 12:41:59PM +0200

On Sat, Sep 21, 2002 at 12:41:59PM +0200, Bernd Eckenfels wrote:
> In article <Pine.LNX.4.10.10209201753310.25090-100000@master.linux-ide.org> you wrote:
> > Regardless, it takes (fill in the blank) to boldly ask people to add APIs
> > for an industry who is only interested in using and not contributing.
> 
> There is more than one industry interested in it. It simply sucks if your
> kernel panic only because you remove a SCSI cable. IT also sucks if your
> kernel panics only vecause you have a bad block on a Disk.

Both of which I'd classify as bugs.  I recently submitted a few patches
that fix some of the idiotic or bad error handling in the 2.4 SCSI
layer.  Although they didn't completely fix some of the problems, it
did highlight some of the problem areas.

> On the other hand, the reason this has not
> happend just shows us, that it is not trivial to find a second person which
> understands hardware's error behaviour.

Or people with broken hardware don't report that the error paths are
broken; they just fix their hardware.

I have a Syquest 270MB drive here.  Bought from new, but it has never
worked 100% properly.  It mostly complains about media errors and the
like.  After several rounds with Syquest, I lost faith in it.  However,
I still have it.  Why?

I keep test filesystems on the cartridges.  Perfect when I want to run
some tests that could well take out a filesystem, or when I want to test
out the SCSI error handling.  That's how I found that the 2.4 SCSI error
handling code has the possibility to eat disks alive when it encounters
an error.

Would extra API's have helped find this?  Would it have made the driver
more stable?  Would it have caught the bug in my SCSI driver that caused
it not to request sense on error and therefore throw the SCSI subsystem
into a never-ending loop?  The answers are: no, no, no.

Would testing with broken hardware have found this?  Would it make the
driver more stable?  Yes, and yes.

IMO, driver stability comes with testing and review by people who know
both the hardware _and_ who know the kernel API inside out.  There seems
to be a lack the latter, and a lack of people with broken hardware for
the former.

So next time when your hard disk develops media errors, or your network
card starts corrupting data, think about whether it would be a useful
test device to someone.  (Obviously not if its completely 100% dead.)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


  reply	other threads:[~2002-09-21 11:15 UTC|newest]

Thread overview: 24+ 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 ` [ANNOUNCE] Linux [add-more-silly-APIs] " 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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=20020921122041.A27150@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=ecki-news2002-09@lina.inka.de \
    --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