From: "Rhoads, Rob" <rob.rhoads@intel.com>
To: "'Greg KH'" <greg@kroah.com>, "Rhoads, Rob" <rob.rhoads@intel.com>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: RE: [ANNOUNCE] Linux Hardened Device Drivers Project
Date: Tue, 24 Sep 2002 14:46:35 -0700 [thread overview]
Message-ID: <D9223EB959A5D511A98F00508B68C20C0A5389D8@orsmsx108.jf.intel.com> (raw)
> From: Greg KH [mailto:greg@kroah.com]
>
[snip]
>
> > An underlying theme tends to revolve around the binding
> > of the concepts of 'hardening' and RAS features being
> > added to drivers. We will be looking into splitting
> > these two different approaches out from this singular
> > document and into their appropriate locations.
>
> Where would these locations be?
>
First throw away any idea of a spec. That was a bad idea. :)
Next, turn the first section, "Stability & Reliability" of our
original doc into a "Driver Hardening HOWTO". It would be a
list of characteristics that all good drivers should have,
packed with examples to back it up.
BTW, by no means did I or anyone involved on this project, ever
mean to imply that the current drivers in the kernel are "bad".
Rather, I'd like to capture a list of the best practices and
document them. In any event our current list needs to be
strengthened with concrete examples. My thinking is that we
should work with the Kernel Janitor project. This is where
Intel can probably really help out.
The section on Instrumentation should be broken up and each piece
dealt with separately as separate project. Most likely killed outright
or as part of existing efforts. I see this section as not having
anything to do with driver hardening and more to do with driver RAS.
POSIX Event Logging-- is a dead issue. The mailing list feedback
is making that point very clear, many thanks. The current
thread on an alternative, seems like there is some sort of need
for event logging. Whatever the final decision that the Linux
community decides, we'll do.
There seems to be a desire to have some sort of driver diagnostics.
We can work on that with the existing linux-diag project.
Statistics needs to be debated on its own merits. There are some
arguments for keeping it, but I think that stats could be better
handled in user-space and NOT kernel space. IMHO it's not driver
hardening, therefore it's a separate project.
Third, the most of the section on High Availability should just
be axed. The big exception being "fault injection testing".
I see value in keeping FI testing. I think that getting FI
tools into the hands of developers would be worthwhile. Why?
Because letting people do more complicated testing, produces
better code. I think there is room for us to work on a set of
FI tools.
> > If you are interested (even if you aren't) please go
> > to http://lists.sourceforge.net/lists/listinfo/hardeneddrivers-discuss
> and subscribe to the mailing list.
>
> Sorry, but major kernel driver discussions should occur on lkml.
>
> thanks,
>
> greg k-h
next reply other threads:[~2002-09-24 21:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-24 21:46 Rhoads, Rob [this message]
2002-09-24 23:07 ` [ANNOUNCE] Linux Hardened Device Drivers Project Greg KH
-- strict thread matches above, loose matches on Subject: below --
2002-09-24 23:29 Rhoads, Rob
2002-09-24 19:30 Rhoads, Rob
2002-09-24 19:55 ` Greg KH
2002-09-23 13:23 Manfred Spraul
2002-09-21 3:00 Rhoads, Rob
2002-09-21 3:47 ` Andre Hedrick
2002-09-21 4:09 ` Mark Veltzer
[not found] <mailman.1032570840.22498.linux-kernel2news@redhat.com>
2002-09-21 2:14 ` Pete Zaitcev
2002-09-21 3:30 ` Andre Hedrick
2002-09-21 0:26 Rhoads, Rob
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-23 6:13 ` 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=D9223EB959A5D511A98F00508B68C20C0A5389D8@orsmsx108.jf.intel.com \
--to=rob.rhoads@intel.com \
--cc=greg@kroah.com \
--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;
as well as URLs for NNTP newsgroup(s).