Writing an OS for PC (fwd)

[Francois-Rene Rideau]

Dear TUNESers,
   David Logan <73114.3621@compuserve.com> posted a message in
comp.os.research about his pet OS project. I proposed he join us,
and here is his answer (my answer back in next tunes post)...

------>8------>8------>8------>8------>8------>8------>8------>8------>8------

>From 73114.3621@compuserve.com  Sat May 27 19:31:17 1995
Received-Date: Sat, 27 May 95 19:31:17 +0200
Date: 27 May 95 13:29:47 EDT
From: David Logan <73114.3621@compuserve.com>
To: <rideau@clipper.ens.fr>
Subject: Writing an OS for PC
Message-Id: <950527172947_73114.3621_EHJ161-2@CompuServe.COM>

-----BEGIN PGP SIGNED MESSAGE-----

Francois -

  Hi!  I don't know at this point if I'm interested in helping you work on your
operating system.  This being said primarily due to the fact that I don't know
what kinds of plans you have.  Allow me to provide the letter that I am
providing to people who believe they are interested in helping me.  If it
sounds interesting to you, perhaps we can talk some more. Thanks!
==============================================================================
   Hello, and thanks for the reply.  Every OS designed has to be based off of
something, I guess. (Or multiple somethings).  Let me see if I can sum up some
of what I'm trying to do.

  1. Of course, true preemptive multitasking.
  2. Of course, true 32-bit programming.
  3. Refrain from HUGE amounts of memory required to run the OS, like some
     other OS's that I know.  Keep in mind that this may conflict with the
     goals below.  However, if it does, then the goals below become the
     priority, because at least lots of functionality comes from the size.

   Now for some of the things that I want that most other OS's don't have.

  1. VERY extensive error recovery and error handling.
     a.  The OS itself NEVER crashes unless some PL0 task trashes me BEYOND
         REPAIR.  (This implies an attempt to repair and recover).
     b.  All tasks, all functions are given the opportunity to recover/repair
         their own errors instead of just being killed.
     c.  Dumps, traces, etc. of where tasks came from, where they went, what
         happened, how everything looks, etc. for problem resolution when
         something does go badly.

     One of the things that has pissed me off no end is that no PC OS even
comes close to having problem determiniation aids outside of a single-step
debugger.  In this area, I'm working on using concepts that come from IBM's MVS
operating system.  (You'll notice that several ideas come from there).

  2.  Reportability and accountability.  I want to know what my machine is
      doing, why, when, how long, and who is causing it.

  Note here, that the likelyhood of this OS being designed for "home use" is
probably about 1%. (Less, probably).  Again, the concepts are being based off
the mainframe OS.  The idea came from my LAN admin (at work) telling me that
he couldn't report on anywhere near the types of things that I can (in the
mainframe world).

  3.  Support for multiprocessing.  I'm including as much code as I can for
      multiple processor support.

  Obviously, for a while a lot of the MP code will just be anchored (i.e. just
a RET statement), but as much as I can include and support for future use I am
doing.

  4.  Versatility.

  User programs, intermediate 3rd party products, administrator-written user
or OS code, etc. can be very versatile, using the system in whatever ways they
need or would like.  Good networking capability, excellent (as much as possible
with the Intel hardware support) cross-memory services, etc.

  5.  There's more, but it has escaped me for the moment.  If we talk again
based on this letter, I'm sure you'll hear some more ideas.

  Keep in mind that I don't believe I am a mainframe bigot.  I've been an
expert in both mainframe and PC's for years and years.  However, also keep in
mind that IBM has been developing high performance, multitasking,
multiprocessing operating systems for years, and their ideas, concepts, and
implementations are quite good.  If we can figure out how to implement those
same concepts (as in error handling, recording/tracking, task versatility,
etc.), it has the capability to provide businesses with a full featured,
reliable, usable, excellent OS.  Especially as PC's evolve in power and
functionality.

  Specifically, some of the things that I have in the plans or are working on
implementing:

  1.  Only two selectors in the GDT are static (also only 2 in the LDT).
      The 2nd is the selector to the Common Memory Area in the GDT, the Local
      Memory Area in the LDT (OS reserved virtual storage).
  2.  OS memory can be fixed or pageable.  It can also be protected or
      non-protected.  The selectors themselves are DPL3, allowing user tasks to
      read most of OS storage, but not modify it (based on page table R/W bit).
      Obviously, some things must reside in protected storage (U/S bit = S),
      like network buffers, security package control blocks, etc.
  3.  An address space (or sets of segment/page tables) are not related to a
      task (or TSS).  Multiple tasks can be run under an "address space".
  4.  Recovery/termination.  Any task can make an operating system call at any
      time to establish an "error recovery" routine to be called in the event
      of an error.  This routine can correct/bypass the error, and request the
      OS retry the origional routine, or continue the termination process.
      Required in all OS routines, especially in global ones that can be done
      under any TSS.  Also required in any tasks/address spaces that would hang
      the system in the event of a failure.
   5. Special environments for the double fault, NMI, and stack fault handlers.
      Make EVERY effort to protect these tasks code/control blocks so in the
      event of a serious failure, the system doesn't hang.  These routines will
      support dumping of the system for problem resolution.  (Dumping of all or
      parts of the system are supported in all cases, initiated either by the
      OS or a user task.  It's just that these three tasks are very critical to
      recovery of the OS, and at least problem resolution if recovery is
      impossible).  The stack fault handler becomes "special" only in the event
      that a stack fault occurs on a PL0 stack.
   6. A million others, but these should give you a taste of what I'm reaching
      for.

  If you're still interested after reading this book, let me know!  I'd be glad
to hear new ideas, implementation concepts, and even willing to help code!

                                          David Logan,
                                          Boulder, CO



-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQB1AwUBL8dhnxylXvjtppttAQGrlQL+Nk+SKi/OnQG2fxdt4nhGUGPAbV7T6Pfd
dLS9AyvtqB7K3+U/Y36BqjhudW9gvCZpixdX4qD2YUW5ZlORXLt7wkeJGSms45vs
Xc1fhf5SSHs10rbaULQajksx+qkeHp/a
=WPnk
-----END PGP SIGNATURE-----

------>8------>8------>8------>8------>8------>8------>8------>8------>8------
(end of forwarded message)

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://acacia.ens.fr:8080/home/rideau/Tunes/"