From: wittbj@cube05.ccs.csus.edu (brian witt)
Newsgroups: comp.os.research
Subject: Re: Have we learned anything in the last 20 years?
Date: 9 Apr 92 02:38:30 GMT
Article-I.D.: darkstar.32429
Organization: California State University: Sacramento, USA
Originator: osr@ftp

In article <32101@darkstar.ucsc.edu> niran@laurel.cis.ohio-state.edu (Niranjan G Shivarat) writes:
>In article <32014@darkstar.ucsc.edu> ast@cs.vu.nl (Andy Tanenbaum) writes:
>>STILL HIGHLY CONTROVERSIAL
>> [..}
>>Andy Tanenbaum (ast@cs.vu.nl)
>
>May be the following is also a suitable for the above category. 
>
>There are many experimental distributed systems which are object-oriented.
>
>Is there any consensus on whether object-oriented is the way or not the way to
>develop distributed operating systems in the future?
>
>On the other hand, is it the case that object-oriented is good under certain
>conditions and non object-oriented is better under some others?

Some of the real-time research kernels appearing claim object-oriented-ness
However, they may be object_based, instead.  if good enough for 
real-time, it must be usable.  Mach 2.0 does paging faster on a VAX than
bsd 4.2 (cf. some conference proceedings).

A friend and I just completed building a "toy" operating system using C++.
We wanted to make objects out of many of the kernel resources.  The class
design was kinda micro-kernel-ish (other people in the class used Modula-2).
(Perhaps minimal kernel would be a better description.)

I enjoyed using G++. But time limits and the difficulty of interfacing
the application to the kernel objects limited what we did.  If we
actually _completed_ the system, my views would be different.
Here are some feelings, pro and con, about the project...
(This posting grew as I thought more about it... :-)


PLUS:
=====
* Designing with objects for the process, message and mailbox management
produced some incredibly reliable code!  Reason: Michael was able to test
the code out on an IBM PC using a test harness.  The strong encapsulation
meant a "skimpy" test harness could be built.

* The design and coding was easily paritioned between Michael and I.
We choose domains, developed interfaces, and went from there.

* Disk drivers were very easy to construct.

* The queuing between application and char device, and char device
and serial port ISR was easily reused.  Others, using Modula-2, had
lots of duplicated code here.

MINUS:
======
* Character device classes were *real* twisted.  We concentrated on code
reuse perhaps a little _too_ much.  But the steps to read a byte and
store into a queue were spread out in three files and two headers! :-(
(I'm trying to rewrite them -- got some really cool ideas!)

* There usually is only two or three disk controller interfaces...

* If you must single step, you need a bunch of file listings to know
where you are.  C++ runs betwen headers and many inheritted source files.

* I think some speed was lost in the dynamic method passing.  Inside the
kernel messaging was OK, but how to allow a user process to message
(and possibly inherit and override) a method to some kernel object
it was holding onto was an issue was avoided. (The class was about
the kernel, not application call interfaces.)

* There was no "prebuilt (or pre-specified) data structure library"
to draw upon.  We read the books and created a class, but there were
no canned libraries to re-use. (The Smalltalk class `Process' was
a little too general for our use.)

* We built the toy OS incrementally. Ie, first we did polled mode,
the interrupt mode character I/O.  This was a waste of coding time.
Should have just gone for interrupts right off!

* Great Sadness: The application interface had to be traditional (procedure
based).  A wonderful object design could emerge, but if the application
interface isn't traditional, then only a particular OO language can
interface with it.


-- 
======================================================================== !
   Brian Witt     [Sac State Comp Science]   "Waldo, the pariot, is dead"
   Internet:  wittbj@cube01.ccs.csus.edu               -- Agent Cooper
                  #define  POSIX_ME_HARDER     1      <-- GNU