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
next prev 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