NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/research/1141

Internet Message Format | 1992-12-15 | 4.0 KB

Path: sparky!uunet!olivea!hal.com!darkstar.UCSC.EDU!osr
From: [e-mail] (Joshua A. Tauber)
Newsgroups: comp.os.research
Subject: Re: On debugging (was Re: Microkernel for Real-Time Computing)
Message-ID: <[e-mail]>
Date: 15 Dec 92 20:41:17 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Matsushita Information Technology Laboratory, Princeton, NJ
Lines: 72
Approved: [e-mail]
NNTP-Posting-Host: ftp.cse.ucsc.edu
Originator: osr@ftp

In article <[e-mail]>, [e-mail] (Tage Stabell-kuloe) writes:

|>
|>     The original thread was discussing kernel debugging and OS design.  The
|>     message which I commented stated [quoted from "An Architectural Overview
|>     of QNX", by Dan Hildebrand, [e-mail]]:
|>     "A fundamental problem with the maintenance of a monolithic kernel
|>     operating system is that all of the kernel code runs in a common,
|>     shared address space.  The danger  that one portion of the kernel
|>     might corrupt the data space of another is very real, and must
|>     be considered every time new drivers are linked into the kernel.
|>     The approach taken by QNX is to explicitly define the interface
|>     between the components that make up the OS, such that each resource
|>     manager, just like user processes, runs in its own memory-protected
|>     space, and all communication between the OS modules is through
|>     standard system IPC services.  As a result, errors introduced by
|>     one resource manager will be constrained to that subsystem and will
|>     not corrupt other, unrelated resource managers in the system."
|>
|>     The fundamental question is:
|>     Why are services moved out of the (monolithic) kernel ?
|>     The answer is usually (as in the quote above)
|>     To avoid errors _in the implementation_ to spread.
|>
|>     Which (in this context) is a software-engineering solution to a
|>     debugging problem.
|>     There is no such thing as a free lunch.  It is more expensive for one
|>     service in the kernel to [insert your favourite IPC mechanism here] in
|>     order to inform another part of some event, then just jumping to it.
|>     But note that the cost is measured in time, while in the above quote the
|>     cost is measured in "debugging".
|>
|> >[e-mail]
|>
|>
|> --
|> ////      Tage Stabell-Kuloe            |e-mail   : [e-mail]   ////



While this is a software engineering method, I would not label the
problems it solves merely "debugging". I would add fault-tolerance,
maintanability, & forward compatibility to name just a few issues.
While the latter two derive from the modular nature of the code, the
first is a fundamental difference.

There is a qualitative difference between services sharing one address
space and services acting in protected address spaces.  Note, the code
may be no more correct but when it fails the behavior will be less
catostrophic.  Do not expect a major piece of software to be
completely bug free.  It isn't going to happen.  So when failures do
happen, we would like the best possible behavior from the system
("graceful degredation" and all that - but that's a different thread).

Thus, the measurement here is not just in programmer's time
("debugging") but robustness.

[Can this difference be translated into  "programmer's time" by saying
that with X amount of programmer's time the two pieces of code will be
equally correct and handle failures equally well?  That one I can't answer.]

                    -jat42

Joshua A. Tauber
Matsushita Information Technology Laboratory  | Email: [e-mail]
182 Nassau Street, Third Floor              | Phone: [phone]
Princeton, NJ  08542-7072 USA              | Fax:   [phone]
--
Joshua A. Tauber
Matsushita Information Technology Laboratory  | Email: [e-mail]
182 Nassau Street, Third Floor              | Phone: [phone]
Princeton, NJ  08542-7072 USA              | Fax:   [phone]