No subject

[Gary D. Duzan]

In Message <2bfb0cb6.davgar@davgar.arlington.va.us> ,
   David Garfield <david@davgar.arlington.va.us> wrote:

=>> If we can build the IPC primitives within an object, it should be possible,
=>> to create two (2!) kernels: one synchronous and one asynchronous. As the 
=>> interface should be the same, there should be no problem to the application
=>> layer and to the lower layers as well. We can then compare these two or
=>> even offer both.
=>
=>Now you want two(!) kernels!?!?  Do you think we are masocists?  I 
=>mean, they can't be the same OS.  They would require two completely 
=>different sets of support software ...
=>
   Yes, this would be bad. IPC semantics need to be consistent.

=>"> " is Gary D. Duzan
=>">=>" is David Garfield (me)
=>">=>> " is Dennis Marer
=>">=>>> " is Gary D. Duzan

=>>   Well, if we use Ellie, we can always use future return objects. :-)
=>
=>Sounds like its just a language construct for asynchrous messages. :-)
=>
   The call is always synchronous, but in the future case, the return
is asynchronous. Accessing a future object state results in what
amounts to a synchronous call that returns the state.

=>I think we won't have much choice, but it may be reasonable for a 
=>image to specify that only one thread may be active at any time, all 
=>others must wait to get in (subject to rule changes to prevent deadlock).
=>
   The Ellie language has a neat idea called a dynamic interface.
An object itself may determine which methods may be accessed at a
given time, providing for mutual exclusion. We might adapt the idea
for Moose objects.
   If I seem to have a slightly odd view of objects lately, it is
probably because I have Ellie on the brain. It *is* a cool language,
though. Did anyone get around to reading the papers on it?

=>>   Very sparse address spaces and encryption can be used, as in the
=>>Amoeba system. Sparse addressing (i.e. say, a 128-bit number with
=>>object numbers scattered around in it) may be sufficient for a local
=>>system.
=>
=>Even if you do pick them at random in a sparse address, you are only 
=>getting good chances of preventing forgery, not proof.  Remember, if 
=>the OS is not protected (i.e. PROOF) against the applications, any 
=>application can trash the OS.  We call this an unprotected operating 
=>system.  DOS is unprotected.  
=>
   And I suppose you prove the correctness of all the programs you
write, too. :-) If it is going to take 2 years to try addresses at
random to get a hit, that may be good enough. There certainly needs
to be memory protection between objects, between objects and the OS,
and between objects and the hardware. I doubt we would ever get C-2
security certification, anyway, and most users don't need inordinate
levels of security.
   Also "DOS implies unprotected" is not equivalent to "all that is
unprotected is DOS". Protection is a relative thing. Is your machine
protected against my flipping the power switch? Openning the case and
installing a bus tap? Monitoring you serial port or network connection?
Sending you tons of annoying Email? :-)

=>>   Quite so. Unless the hardware has some IPC support, it has to
=>>be in the kernel. The 386 seems to be one of the exceptions in that
=>>the gates (if I remember correctly) can be used here. Other machines
=>>aren't so fortunate. Regardless, it needs to be in the kernel API
=>>whether it actually goes to the kernel or not.
=>
=>All CPUs with multiple protection levels will have a method for a user 
=>level program to invoke something at a higher protection level, and 
=>pass some sort of parameter.  The unusual part of the 386 is that the 
=>parameter is that any of several calls can be used.  Most hardwares 
=>just let you pass an n-bit constant.
=>
   Right, but I was looking at a feature of the 386 (I forget which)
that would allow direct, secure calls between segments using normal
function calls, not going through the kernel or anything else.

=>>   Quite so. So are we going to implement StreetTalk for Moose too? :-)
=>
=>If you can come up with a useful protocol and if failure to provide an 
=>implementation for the protocol will result in different people 
=>writing different implementation for it, then we need to provide an 
=>implementation as part of the original development.  At this time, 
=>TCP/IP fits the bill, as do SCSI hard disks, and MFM/ESDI/IDE hard 
=>disks, and VGA and SVGA displays.  Other protocols and interfaces may 
=>also qualify.  
=>
   I see no reason to provide TCP/IP before releasing a working
package. Certainly we must support standard hardware on supported
platforms. We would probably want to have some sort of
coordination effort among those who would build services and
applications on Moose.

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts