RE: [ANNOUNCE] Linux Hardened Device Drivers Project

[Rhoads, Rob]

> From: Greg KH [mailto:[e-mail]]
> 
[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