Messages in this thread | | | From | "David Schwartz" <> | Subject | RE: wake_up_interruptible changes | Date | Wed, 15 Dec 1999 16:40:57 -0800 |
| |
> 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.
Why would you prefer that someone with no familiarity with your life-safety issues change the macros that your code uses -- causing code you wrote to behave differently in ways the you did not intend and perhaps are not aware of?
You have two choices. You could stick with one kernel version, understand it inside out, and be assured that it will continue to do what it has always done. Or you can change kernel versions, but each time, you *WILL* have to make sure that anything critical still works the way you think it worked.
It is no easier to evaluate that an unchanged piece of code still works as intended in a changed environment with changed header files than it is to change a piece of code slightly to work as intended in a changed environment.
DS
- 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/
| |