Review: Reliabilty of Commodity OSes

From: Steve Arnold (steve.arnold4_at_verizon.net)
Date: Tue Jan 20 2004 - 21:44:05 PST

  • Next message: Greg Green: "Improving the Reliability of Commodity Operating Systems"

    Recognizing that a great deal of crashes come from "extensions" (mostly
    device drivers), the authors of this paper put forward a system to deal with
    these. Their approach is not to improve the extensions, but to change the
    way they call into the kernel and to provide a recovery method for when they
    do fail. They tried to do this in such a way that it is completely
    compatible with existing systems.
     
    The implementation consists of several parts. There is an isolation part
    where they have created XPCs to act as the control transfer between the
    kernel and the extensions (not done directly). All the existing function
    calls had to be wrapped. The interposition part is the changing of the
    function calls to go through these wrappers. They have to do some object
    tracking in order to implement the recovery part.
     
    In their test results, they found that Nooks saved the system 99% of the
    time (we're not sure what was lost - but the system keeps going). In their
    results, they found that the more XPCs that had to be called, the more of an
    effect on performance there was.
     
    After you read this paper, you start wondering why existing operating
    systems don't do something like this (or at least part of it). For some
    applications, the drop in performance is certainly a drawback. It's
    unfortunate that you need this kind of system, as it would be nice if
    extensions were just written more reliably in the first place. In some
    cases, it seems the authors still had to write custom code, some I'm not
    sure I buy that it was completely transparent.
     
    This paper was easy to read and well-written.
     


  • Next message: Greg Green: "Improving the Reliability of Commodity Operating Systems"

    This archive was generated by hypermail 2.1.6 : Tue Jan 20 2004 - 21:43:45 PST