Messages in this thread | | | Date | Thu, 16 Dec 1999 08:43:01 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | RE: wake_up_interruptible changes |
| |
On Wed, 15 Dec 1999, David Schwartz wrote:
> > > This breaks every Linux driver that implements poll/select, meaning > > that once released, all such drivers will have to be rewritten, not > > just compiled. > > > > Is it possible that these kinds of changes could be implemented in > > the future as MACROS so that one doesn't have to rewrite released > > code? > > > > The problem may not be evident to a lot of persons unless they > > are trying to use Linux in a commercial environment. We have, > > currently under development. a Medical Imaging System > > (a CAT Scanner) with a main controller, the thing that does all the > > sequencing, and control of the entire machine, written in the Linux > > environment. This required drivers for all the non-standard > > communications, control, and image processing hardware to be written for > > Linux. > > > > This machine, because it is used in medical applications, must > > be certified by the FDA. By the time this machine is complete > > and ready for certification, (in about 2 years) many new > > versions of Linux will have been released. If anything having > > to do with the basic control (read safety) is changed, the > > machine must be re-certified. This means that we either use > > a current standard "release" with all its bugs and old technology > > and stick with it forever, or we attempt to keep the software up-to-date > > so that, by the time the FDA certification occurs, we are able to use the > > "latest" released kernel. > > I could not disagree with you more. If there really are life-safety issues, > the code *should* break badly (and should be designed to break badly) when > its dependency code is changed. And it should require someone familiar with > the life-safety issues to go in and fix it before it compiles again.
You read much more into what I wrote than what I wrote. We intend to keep our code more-or-less "current" so that, when it comes time for the certification process, the "latest and greatest" stable release will be used. It can be used because we have kept current.
A bit of forethought on the part of persons who modify kernel interface structures can go a long way towards that goal.
Cheers, Dick Johnson
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips). Warning : The end of the world as we know it requires a new calendar. Seconds : 1351019 (until Y2K)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |