lkml.org 
[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: wake_up_interruptible changes
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.032 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site