public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
	Jeff Garzik <jeff@garzik.org>,
	linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@SteelEye.com>
Subject: Re: [patch] scsi: fix crash in gdth_timeout()
Date: Tue, 16 Oct 2007 00:23:06 +0200	[thread overview]
Message-ID: <20071015222306.GA19773@elte.hu> (raw)
In-Reply-To: <alpine.LFD.0.999.0710151232430.6887@woody.linux-foundation.org>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 15 Oct 2007, Ingo Molnar wrote:
> > 
> > heh. Incidentally i was thinking about using KVM for automated 
> > testing.
> 
> Using emulators to test device drivers is almost certain to be 
> pointless.

something like that wont enable 100% coverage (or even reasonable 
coverage for most hardware), so it's no replacement for actual hard 
testing, but it could push out the domain of minimally tested code quite 
a bit and increase the quality of the kernel. Races are always tough and 
so are bugs on the side of the hardware, but it's the silly boot-time 
crash showstoppers and "device does not work anymore" mistakes that 
causes us to lose most of the testers and early adopters.

I'm not really worried about the 1% of bugs that are tough to find and 
fix (because they are actually fun to find and fix), i'm worried about 
the 99% easy and boring bugs - because they annoy users just as much as 
the exciting bugs do. If we fix them faster then there's more time (and 
more tester stamina) left for the harder to find bugs.

so i think adding redundancy in form of a simplified hw emulator can 
certainly not hurt and fundamentally increases robustness - and it will 
definitely reduce the chance for a whole host of stupid bugs that are 
not in the hardware but are in the ~4 million lines of Linux driver 
codebase. Limits and scalability would also be testable: "if i put 32 of 
these networking cards into a Linux box, will the Linux driver blow up".

not that i think this is realistic for any significant portion of the 
hardware currently - unless some hw maker starts doing it. But KVM will 
have a good portion of the core PC platform emulated (APIC, etc.) - and 
that's a nice step forward already.

	Ingo

  parent reply	other threads:[~2007-10-15 22:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-15 16:55 [patch] scsi: fix crash in gdth_timeout() Ingo Molnar
2007-10-15 17:08 ` Linus Torvalds
2007-10-15 17:57   ` Jeff Garzik
2007-10-15 18:43     ` Boaz Harrosh
2007-10-15 19:27       ` Ingo Molnar
2007-10-15 19:38         ` Linus Torvalds
2007-10-15 20:08           ` Alan Cox
2007-10-15 20:15             ` Linus Torvalds
2007-10-15 22:23           ` Ingo Molnar [this message]
2007-10-15 19:24   ` Ingo Molnar
2007-10-15 21:55   ` James Bottomley

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=20071015222306.GA19773@elte.hu \
    --to=mingo@elte.hu \
    --cc=James.Bottomley@SteelEye.com \
    --cc=bharrosh@panasas.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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