From: Lars Marowsky-Bree <lmb@suse.de>
To: "Rhoads, Rob" <rob.rhoads@intel.com>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [ANNOUNCE] Linux Hardened Device Drivers Project
Date: Mon, 23 Sep 2002 14:31:14 +0200 [thread overview]
Message-ID: <20020923123114.GC6790@marowsky-bree.de> (raw)
In-Reply-To: <D9223EB959A5D511A98F00508B68C20C0A53899F@orsmsx108.jf.intel.com>
On 2002-09-20T17:26:47,
"Rhoads, Rob" <rob.rhoads@intel.com> said:
Hi Rob,
I fully support the idea to audit the Linux device drivers - using guidelines,
hardware fault injection, stress testing etc - and fixing any potential bugs.
This is obviously a very important task, because the drivers are some of the
most ugly code I've seen in the kernel.
"Pro-active monitoring", ie by basically gathering whatever statistics are
available and feeding them to some sort of user-space application and then
trying to deduce a potential failure is also a very valuable goal; so exposing
more statistics seems definetely good, too. As long as that doesn't introduce
even more errors...
Any help you can offer on the above is surely appreciated by all involved and
will have a direct, positive impact on Linux.
That said, and the fluff in your specification aside (which was very likely
necessary for management ;-), your spec certainly contains some good points on
how to write stable and robust code. (Aside from the comments the others have
raised already regarding event logging and that of course all recommendations
need to be thoughtfully applied to the case in question)
The statistics can best be exposed via driverfs or /proc (for kernels which
don't have driverfs); however, the statistics analyser nor the SNMP agent
pre-processing belong into the kernel itself. Keep the drivers as lean as
possible, that will introduce less errors at this level. I object to the CSM
being in kernel space. Having a more or less common API for the statistics to
be gathered and exposed by the drivers would be highly valuable indeed though.
What are your further timelines?
A lot of the above - ie, audit and test current drivers - can be done without
(at least not with much more) further planning; I'm always rather amazed at
how much effort Intel, IBM and their child OSDL spent on pretty specifications
which could also be applied to real work ;-)
Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
--
Principal Squirrel
Research and Development, SuSE Linux AG
``Immortality is an adequate definition of high availability for me.''
--- Gregory F. Pfister
next prev parent reply other threads:[~2002-09-23 12:25 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
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 [this message]
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=20020923123114.GC6790@marowsky-bree.de \
--to=lmb@suse.de \
--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