Returned mail: Service unavailable

[Gary D. Duzan]

   Anyone want to explain this message?

=>   ----- 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

=>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.

   I don't recall seeing it before, so it is good that you resent it.

=>> Regards writing the kernel in assembler -- we can break the kernel up into
=>> machine dependent and machine independent parts and write only the former i
n
=>> assembler.
=>> 
=>> I think the less assembler we use the better.

   I'm afraid Dennis will be feeling like we are ganging up on him by
now. :-/

=>> As our resident time lord has pointed out there is very little on processes
=>> and IPC.

   Well, without them we'd be redesigning MS-DOS. We don't want that, now
do we? :-]

=>> > 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 explic
itly
=>> requested.

   Agreed. Personally, I'd rather not expose the user to shared memory
at all.

=>> I like the MEM_PHYSICAL flag.

   If we restrict it properly, it could be useful. We may also want a
MEM_PERSIST flag to indicate that a page should be written to stable
media soon after modification (though I'm not certain how easy this
would be to implement.)

=>> > '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.

   I'd suggest the latter, and while not explicitly stated, I think it
is implied above.

=>> >      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 syste
m
=>> allocates a task memory beginning at (virtual) memory location 0 ...

   Simple enough to fix: just don't do that. :-)

=>> 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.

   Agreed. If it can be integrated with language-based exception
mechanisms, even better.

=>> > E. System Clock and Event Scheduling
=>> > 
=>> > >> How should this be done?
=>> 
=>> Have a device to handle this. 

   Maybe we should call them "system modules" instead of "devices". The
latter can be a subset of the former, that being the set of scheduled
objects with special system priveleges.

=>> > F. Interrupt Handling
=>> > 
=>> > >> How should this be done?
=>> 
=>> I favor a simple interrupt routine that "converts" an interrupt to a messag
e.
=>> Of course some interrupts WILL need to be handled by an interrupt routine b
ut
=>> in general they should be converted into messages.
=>> I feel that this will simplify the writing of device drivers.

   Agreed.

=>> Objects:
=>> I like the approach of simply defining a standard format.

   Abstract classes?

=>> > from its sleep and may enter its critical section.
=>> > 
=>> > 	semaphore@Down()
=>> > 
=>> 
=>> Why the "@" in semaphore@Down ?

   I would assume it is meant to be a method activation operator (i.e.
invocing method "Down" of object "semaphore".)

=>> Nothing is said about how semaphores are created/destroyed.
=>> More seriously nothing is said about how semaphores end up being shared
=>> between two tasks.

   Assuming we have an object name space, they could be located and
referenced like any other object (however that turns out to be.)

=>> Should we have spinlocks too?

   They probably wouldn't buy us a whole lot in a single processor
system.

=>> 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 ...)

   This shouldn't be particularly difficult.

=>> 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.

   Keep in mind that Amoeba file servers also have 128 Meg of RAM. I
don't think Amoeba's file system design decisions are appropriate to
this project, though we can always add it later. We do need to keep
failures in mind, though.

=>> ----------------------------------
=>> 
=>> 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 ...

   My guess would be that libraries are meant to be linked (or mapped)
into objects' virtual space to provide functionality via standard
function calls, while objects would provide functionality via an IPC
mechanism. Providing IPC via libraries can be a powerful technique,
allowing access to system objects through normal language mechanisms.
However, it can also be a language trap when the library becomes the
standard interface (e.g. Unix/C.)

=>> >   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 goi
ng
=>> to be useful.

   I didn't mean to imply that we should only support one high-level
language; I meant to point out that our choice of high-level
implementation language could shape the overall high-level perception
of the system. On the other hand, if we did it right, it might not.

=>> 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 de
vice
=>> drivers and so can be designed without knowing the precise interface) and t
hen
=>> designing the device drivers. This process is then iterated to a fixpoint.

   I think the only real solution is to design the whole system
together. Naturally, the kernel will have to be built first, followed
by system objects and some native development tools, and then the GUI
and applications. The simpler we make the kernel, the sooner we can get
to the higher-level work, but we need to be certain that we have the
proper low-level tools to build our applications.

=>> Regards the Mac OS being in ROM - we can simply let it boot and THEN take o
ver.

   And after all that work that Apple put into it. :-)

=>> (1) What audience are we aiming this OS at?
=>> 	My original understanding was standalone PCs but then you mentioned
=>> 	various network drivers.

   I'd guess that in 5 years you will be hard pressed to find a
standalone PC. People are starting to discover services like Prodigy
(no laughing or vomitting, please :-) and I'd imagine that the trend
will continue.  Eventually, fiber optics will allow data networking for
most homes, and businesses are already tending toward PC LANs. I'd say
that we are missing a great opportunity if we ignore networking in our
design.

=>> 	Do we plan to support (Eg.) diskless workstations?

   I wouldn't call it a priority, but I don't see why we couldn't do it.

=>> (2) We need to have a configuration facility to make installation of new 
=>> 	software/devices/hardware totally painless.

   This is an impossible goal on the ISA architecture. :-(

=>> 	(1) An application doesn't need to know what it's running on

   A computer, of course, silly. :-)

=>> Persistent objects subsume both processes and files.
=>> Getting rid of the concept of the files is (IMHO) a strong forward step.

   Don't let John Ousterhout hear you say that. :-)  (Inside Joke Alert!)

=>> One idea which may simplify swapping is to use a single address space acros
s
=>> all objects -- possibly even the one corresponding to where they are stored
=>> on disk.

   There is certainly a need for a global naming scheme, but I'd be
wary of using pointers in a heterogeneous networked system. Also, some
architectures would support single address spaces better than others.
There may also be a danger of running out of address space (though 32
bits should do for the average user.)

=>> (5) Objects must be first class -- we MUST be able to store objects in vari
ables	, pass 'em to functions etc.
=>> 	The implementation will of course use pointers. This might be a good
=>> 	place to start thinking about capabilities.

   Capabilities are certainly worth considering, especially in an object-
oriented system: You get object naming and access control in one shot.
I'm not sure how you would relate them to pointers.

=>> (6) Security: It hasn't been mentioned yet.
=>> 	Do we want it?
=>> 	To what degree?

   If we are going to support networking, we should have it.
Regardless, we need interface controls to keep the system stable in the
presense of anti-social programs. A capability-based security system
like Amoeba's shouldn't cost too much if we optimize for the local
case.

=>> (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 agains
t
=>> 	trojan horses]

   This is certainly worth considering. Of course, if we get rid of the
concept of a file, then we won't have a "file system", we'll have an
object name space, which is a more general concept (though an equivalent
one, given the Unix purist (e.g. Ousterhout) view.)

=>> (8) Microkernel:
=>> 	Seems to be the way we're heading. Good.
=>> 	
=>> 	* Efficient IPC is important

   Immensely, given a large number of medium to light weight objects.

=>> 	* 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 receive
r
=>> 			for extra speed 

   Standard non-blocking semantics?

=>> (9) Process communication and synchronisation -- a proposal
=>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
=>> 		
=>> Comments?

   Do we really have the need to pass structures with pointers between
objects? The Mach approach might be more fitting: map messages from the
sender's address space into the recipient's address space and send a
pointer to the mapped space to the recipient (when the message is large
enough to justify the overhead of mapping.) Generally, I prefer to stick
to communication semantics rather than ad hoc shared memory communication.

=>> (10) Do we support distributed applications? How?

   A complicated question. As long as we provide good communication
semantics, we could build the support on later.

=>> (11) Where is non-deterministic behavior expressed and how?

   It is generally expressed in humans, from my experience. :-)

=>> (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 debat
e)

   I'm a member of the Threads/Blocking RPC camp as opposed to the
Message Passing camp. Under this philosophy, signals could be
implemented as calls to a control thread (which could potentially fork
another thread to handle the signal.) I believe that system objects can
certainly benefit from multithreading, and it can be a powerful tool
for programming in general.

=>> 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!]

   I've given up my name-changing campaign. There was no concensus at
all in the straw poll, and it isn't too bad, I guess.

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