From owner-freebsd-questions@FreeBSD.ORG Mon Jun 18 05:37:29 2007 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E031F16A468 for ; Mon, 18 Jun 2007 05:37:29 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9618013C487 for ; Mon, 18 Jun 2007 05:37:29 +0000 (UTC) (envelope-from tedm@toybox.placo.com) Received: from TEDSDESK (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) by mail.freebsd-corp-net-guide.com (8.13.8/8.13.8) with SMTP id l5I5bPTR021565; Sun, 17 Jun 2007 22:37:26 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Modulok" , Date: Sun, 17 Jun 2007 22:38:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 In-Reply-To: <64c038660706171939s6651c3a0vd0e52b2e25c5069d@mail.gmail.com> Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mail.freebsd-corp-net-guide.com [65.75.192.90]); Sun, 17 Jun 2007 22:37:26 -0700 (PDT) Cc: questions@freebsd.org Subject: RE: FreeBSD and Robotics X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 05:37:30 -0000 > -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Modulok > Sent: Sunday, June 17, 2007 7:40 PM > To: kzabbo@bellsouth.net > Cc: questions@freebsd.org > Subject: Re: FreeBSD and Robotics > > > It's only as good as the drivers you write to control the robot. It > also depends on just how critical your "critical situations" refers > to. > > In situations where human life is directly dependent upon the > integrity of the system, a modular kernel design has traditionally > been preferred over the monolithic kernel designs found in Windows, > Linux, BSD. That isn't to say that FreeBSD is unstable, in fact it's > very stable. However, in a situation where people die if the system > fails, there are some questions as to the safety of the underlying > designs of these kernels. The reason for this is, (in general), device > drivers operate in the kernel's memory space and therefore have the > potential to bring down the rest of the system, should they fail, > (again, in general). In a modular kernel design, where everything is > run in user-space, if a single driver goes berserk it is entirely > insulated from the rest of the system. > > Then there are embedded systems, which are regarded as more stable > because the hardware they run on is identical from one system to the > next and never changes. Contrast this to operating systems that must > run on a wide range of consumer hardware; there is a statistically > higher probability of mistakes, just due to the increased size of the > codebase. (In practice this doesn't always work out though, as I've > used some embedded systems that were embarrassingly unstable). The > smaller codebase of embedded systems and modular kernels is typically > easier to audit, as there is far less code. Where human life is > directly dependent, the code must be audited by a third party. > There's another issue and that is POST on standard PC hardware. POST takes too long. For example the auto industry has agreed on a standard time that a car engine computer must be fully operational, it is very short, no more than something like 2 seconds or so. Enough so that when you turn the key and the engine starts cranking, that the engine computer has completely booted and is running by the second crank. That is why you probably will never see standard computer hardware used in the operating room of a hospital to control patient life support, for example. If for example during an operation the computer controlling an artificial heart suddenly dies, the staff simply unplugs the lines from the computer and plug them into another computer which then is switched on and within a second has come fully ready, and operating. You could not wait the 30-60 seconds that POST on a regular PC would take to complete. By contrast, regular PC gear is used very much for stuff like image analysis and non-critical gear in a hospital. If the computer running a CAT scanner were to die in the middle of a scan, no big deal, you just replace it and restart the scan from the beginning. Ted