Returned mail: Service unavailable
Mail Delivery Subsystem
Postmaster@cs.mu.OZ.AU
Wed, 17 Feb 1993 17:00:43 +1100
----- Transcript of session follows -----
While talking to whistler.sfu.ca:
>>> RCPT To:<moose-programmers@sfu.ca>
<<< 554 :include:up... Cannot open up: No such file or directory
554 moose-programmers@sfu.ca... Service unavailable
------- Received message follows ----
Received: by mulga.cs.mu.OZ.AU (5.64+1.3.1+0.50); id AA25157
Wed, 17 Feb 1993 17:00:43 +1100 (from winikoff)
Return-Path: <winikoff>
Subject: Re: MOOSE - comments (REPOST)
To: moose-programmers@sfu.ca (Moose Project)
Date: Wed, 17 Feb 93 17:00:42 EST
From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
X-Mailer: ELM [version 2.3 PL0]
I mailed this a while back and haven't seen it or responses to it.
Just in case it wasn't forwarded to everyone I'm remailing it now.
This is comments on the original draft and a few following mails.
Michael
- ----------------------------------------------
>
>
> Comments on design and comments so far
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Sorry I've been a little slow to react -- here are my thoughts.
> Some ideas are at the end -- if you're not interested in wading through the
> comments please skip to the end and read the ideas.
>
> I haven't set up an alias yet -- could you please forward this to everyone.
>
> Thanks
> Michael
> Aka, Merlin, Lord of Chaos, Prince of Amber.
> Computer Designer and creator of Ghostwheel. :-)
>
> ----------------------------------
>
> > The two most important features designed into the Moose
> > operating system will be simplicity and flexibility. For one, a
>
> Simplicity and flexibility are not features they are design guidelines.
> The way to have them in a system is to have them guide all the other design
> decisions we make.
>
> ----------------------------------
>
> > C. User Input Devices
> >
> > With the standard user input devices, it would be ideal to
> > allow keyboards, mouses, and ...
>
> Please - Mice. Not Mouses. :-)
>
> ----------------------------------
>
> ** Could you please explain how object inheritance is done at the OS level?
> In particular how it is done SAFELY?
>
> ----------------------------------
>
> Regards writing the kernel in assembler -- we can break the kernel up into
> machine dependent and machine independent parts and write only the former in
> assembler.
>
> I think the less assembler we use the better.
>
> ----------------------------------
>
> Giving device drivers their own priority -- good.
>
>
> ----------------------------------
>
> As our resident time lord has pointed out there is very little on processes
> and IPC.
>
>
> ----------------------------------
>
> > Most tasks will never need to call these functions explicitly
> > as a certain amount of memory will be allocated to each upon
> > initialization, depending on the compiler used. This larger block
> > of memory should then be broken up by the task into smaller,
>
> No. It's simpler to have the compiler insert code which at runtime calls
> AllocateMemory and uses it's own data structures to subdivide it.
> Automatic allocation of memory isn't needed at all let alone in the kernel.
>
> Bear in mind that users should never use system calls -- the compile should
> provide (eg.) malloc and implement it reasonably.
> Doing that using the system calls is the problem of the compile writer.
>
> ----------------------------------
>
> > most restricted "user" level. All memory allocated will be
> > accessible only by the requesting task and its parent or children
> > tasks, allowing no other tasks access to this memory.
>
> No. I don't like allowing other tasks access to memory by default.
> I'd rather that the default was no access and that shared memory was explicitly
> requested.
>
> My two reasons are
> (1) Robustness -- by allowing a whole hierarchy to read/write a process' memory
> it becomes possible for one of these processes doing something wrong and
> crashing the entire hierarchy.
> (2) Security.
>
> ----------------------------------
>
> I like the MEM_PHYSICAL flag.
>
> ----------------------------------
>
> > There will be a limit on the total number of memory allocations
> > made by a single task and in the system as a whole, so efforts
> > should be made by applications to consolidate memory usage.
>
> This is policy rather then mechanism.
> I think it is better to say "there will be a mechanism by which processes can
> have a limit set on the amount of memory they may allocate"
>
> ----------------------------------
>
> > 'size' parameter. To simplify and expedite memory management, only
> > large chunks of memory will be allocated at one time, usually
> > varying between 1k and 8k in size, depending on the host platform.
>
> This is a implementation decision. I feel that we should either
> (1) Make a fixed decision across all platforms
> Or preferably
> (2) Design the system in such a way that the size of memory allocation does
> not make a difference to the user.
>
> ----------------------------------
>
>
> > The starting address of the memory block will be returned by
> > this function. If the allocation fails a null address is returned,
> > indicated by an address of zero.
>
> Firstly there is scope for a bug here -- consider what happens if the system
> allocates a task memory beginning at (virtual) memory location 0 ...
>
> Secondly and more importantly we need a system wide standard facility for
> communicating back error types and causes -- In order to have sensible
> error reporting we need to return some kind of error code.
>
> ----------------------------------
>
> Is realloc necessary? Can someone come up with a situation where it is
> essential or even important?
>
> ----------------------------------
>
> > E. System Clock and Event Scheduling
> >
> > >> How should this be done?
>
> Have a device to handle this.
> The advantages of doing things in devices are
> (1) The kernel is smaller and simpler
> (2) We can change our mind later and write a different device and
> easily add it to the system.
>
> ----------------------------------
>
> > F. Interrupt Handling
> >
> > >> How should this be done?
>
> I favor a simple interrupt routine that "converts" an interrupt to a message.
> Of course some interrupts WILL need to be handled by an interrupt routine but
> in general they should be converted into messages.
> I feel that this will simplify the writing of device drivers.
>
> ----------------------------------
>
> Objects:
> I like the approach of simply defining a standard format.
>
> ----------------------------------
>
> Files:
> Actually persistent objects subsume files.
> (Simply have an object with one of it's attributes being an array of
> bytes and methods including "read" and "write")
> [More about this later]
>
> ----------------------------------
>
> > from its sleep and may enter its critical section.
> >
> > semaphore@Down()
> >
>
> Why the "@" in semaphore@Down ?
>
>
> ----------------------------------
>
> Nothing is said about how semaphores are created/destroyed.
> More seriously nothing is said about how semaphores end up being shared
> between two tasks.
>
> Should we have spinlocks too?
>
> ----------------------------------
>
> Timers: These seem to be quite complicated.
> I feel that timers can be put into a device rather then being in the kernel.
>
> One possible (simpler) interface:
>
> eventid = schedule(time,event)
> status = remove(eventid)
> eventid = schedulerelative(time_delta, event)
> time = gettime()
>
> In order to simulate timers have a process that does a gettime when it receives
> a message.
>
> In order to simulate periodic events have the the receiver of the message
> reschedule itself.
>
> I'm not certain whether we need facilities to determine how much time a process
> has consumed.
> If we do it will have to be in the kernel since it involves the process
> scheduler.
>
> ----------------------------------
>
> > B. Display Output Devices
> >
> > A proper definition of the state of the display output devices
> > would be an object-oriented GUI similar to X11, only much easier
> > to use. :-)
>
> NO!!!!
> The user interface is a USER program for flexibility.
> The display should offer graphics primitives.
> (Eg. line, text, blit ...)
>
> ----------------------------------
>
> User input:
> It is useful to be able to insert input filters -- processes through
> which input events pass before being sent to their destination.
> (Uses: Screen savers, macro recorders, shortcuts ...)
>
> ----------------------------------
>
> File systems:
> One issue that hasn't been raised is crash recovery.
> I suggest people have a look at Amoeba's file system -- they store
> files contiguously sacrificing disk space for speed.
>
> ----------------------------------
>
> Libraries:
> I'm sorry. I didn't understand this too well.
> Can you please explain them.
> IN particular I'm uncertain as to the difference between objects and
> libraries -- libraries seem to be just typed objects which
> sounds like what you were trying to avoid in ...
>
> > Strictly speaking, the operating system will define nothing
> > more than a standard format for storing a class and a methodology
> > for accessing its attributes and methods in a meaningful way. No
> > enforcement of these policies will actually be done to allow for
> > maximum flexibility and efficiency. If objects are not implemented
> > correctly by an application or device driver, the loss will be only
>
>
>
> ----------------------------------
> ----------------------------------
>
> That concludes my comments on the initial spec.
>
> I've got a few comments on the various comments that other people have made
> so far.
>
> Also I'd like to throw a few ideas after that.
>
>
> ----------------------------------
>
> Gary Duzan
> ~~~~~~~~~~
>
> I think we SHOULD provide a CLI (Command Line Interface) -- their very useful
> when porting Unix based software.
>
> > So what language do we write the high-level stuff in? Should it
> > matter? Can we make it not matter?
>
>
> We MUST make it not matter. An OS that only supports one language isn't going
> to be useful.
>
>
> ----------------------------------
>
> Fare'
> ~~~~~
>
> Agree. The system should be written in a HLL. C has had an influence on Unix etc
>
> > To conclude, I think we mustn't rush doing what would be the kernel of a
> > system whose features aren't defined yet. Let's define the high-level object
> > orientation of the system before we write the kernel (more precisely, let's
> > not write something in the kernel we should have to change completely because
> > it will not fit high-level system requirements).
>
>
> I disagree - I feel that the kernel should be designed first with the
> applications in mind.
> Lets face it -- this is a chicken and egg problem: The kernel and the
> applications (including device drivers) depend on each other's design.
> The solution is to start with the kernel (which doesn't actually use the device
> drivers and so can be designed without knowing the precise interface) and then
> designing the device drivers. This process is then iterated to a fixpoint.
>
>
> ----------------------------------
>
> Regards the Mac OS being in ROM - we can simply let it boot and THEN take over.
>
>
> ----------------------------------
>
> Some ideas and suggestions -- PLEASE READ THIS BIT
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> (1) What audience are we aiming this OS at?
> My original understanding was standalone PCs but then you mentioned
> various network drivers.
> Do we plan to support (Eg.) diskless workstations?
>
> (2) We need to have a configuration facility to make installation of new
> software/devices/hardware totally painless.
> This of course, will not be in the kernel however I thought it
> worth mentioning.
> We should set things up so that either
> (1) An application doesn't need to know what it's running on
> (2) An application can easily find out what services the system provides
>
> This is particularly important since an application may find that
> certain device drivers have not been mounted.
>
> (3) (I've mentioned this b4) We need a facility for returning error codes
> when a system call fails.
>
> (4) Objects, Files, address spaces and all that jazz ...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Persistent objects subsume both processes and files.
> Getting rid of the concept of the files is (IMHO) a strong forward step.
>
> One idea which may simplify swapping is to use a single address space across
> all objects -- possibly even the one corresponding to where they are stored
> on disk.
>
> Of course most of the address space will be inaccessible ...
>
> The main advantage of this scheme is that it makes shared memory simpler to
> program with -- otherwise pointers have to be avoided since the addresses
> will differ from process to process.
>
> [But see arenas later]
>
> (5) Objects must be first class -- we MUST be able to store objects in variables , pass 'em to functions etc.
> The implementation will of course use pointers. This might be a good
> place to start thinking about capabilities.
>
> (6) Security: It hasn't been mentioned yet.
> Do we want it?
> To what degree?
>
> (7) I/O redirection:
> Idea: Have the following convention: when an object is started it
> is given by it's creator the objects representing stdin stdout etc.
> (It may be more appropriate to think of screen, kbd etc.)
> This lets us easily do I/O redirection -- simply have the shell
> substitute say, a file for the keyboard or a printer for the screen etc.
>
> [Note: The list of initial objects could perhaps include ALL objects
> used (Eg. file system) for maximum flexibility -- this would then also
> let us run a program in an isolated environment ... good defence against
> trojan horses]
>
> (8) Microkernel:
> Seems to be the way we're heading. Good.
>
> * Efficient IPC is important
> * Possible interface:
> send -- sends a message to an object
> receive -- returns the next object. Pauses caller if none
> available.
> call -- Like a send but does a context switch to the receiver
> for extra speed
> spawn (or create_object)
> kill -- destroys an object, freeing it's resources
> self -- returns the id of the caller. One use is "kill(self)"
> instead of a special exit call.
> alloc -- AllocateMemory
> free -- FreeMemory
>
> The main missing calls in the interface are process communication and
> synchronisation.
>
>
> (9) Process communication and synchronisation -- a proposal
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Process communication requires an efficient means of passing large
> amounts of information between processes.
>
> The one commonly used is shared memory -- the problem is that pointers don't
> work.
>
> I would like to suggest a variation which I'd like to call "arenas"
> The idea is that the arena is like shared memory except that when created
> it is specified to which virtual memory addresses the arena should be bound.
>
> Any process that attaches to the arena has it mapped to the same virtual memory
> addresses so pointers can be safely used as long as they remain pointing within
> the arena.
>
> Regards synchronisation -- semaphores are a fairly common primitive.
> Rather then having objects we can simply have operations "up" and "down" that
> take a pointer to an integer.
>
> By convention the first 4 bytes of an arena can be used as a semaphore for
> mutual exclusive access to the arena. This is only a convention and is not
> enforced anywhere.
>
> Comments?
>
>
> (10) Do we support distributed applications? How?
>
> (11) Where is non-deterministic behavior expressed and how?
>
> (12) Do we support some notion of "signal" -- ie. pre-empting messages?
> Should we? (I don't know)
>
> (13) Should we be providing threads? (I don't think so but am open to debate)
>
>
> Last but not least ... the name MOOSE.
>
> I like it. It's MEMORABLE.
>
> Can people please tell me why they don't like the name?
> [Or if they do like it please speak up!]
>
>
> --------------------------------------------------------------------------------
> Michael Winikoff
> winikoff@cs.mu.oz.au
> Computer science honours. University of Melbourne, Australia.
>
------- Received message ends ----