Just can't get enough of that Moose!

[Dennis Marer]

Howdy all!

	Yet another message here...

>Do I have to do anything to subscribe to the list service?  I thought I read
>something in a message sent to me that anybody who got that particular message
>had already been subscribed.  I have gotten two messages from
>postmaster@cs.mu.oz.au that say something like
>
>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
>
>and then a forwarded message containing some discussion regarding Moose.

	I was getting these messages too for a while - doesn't seem to happen
now.  You're all already subscribed, and can use this address to send mail!
Give it a whirl!

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

Nope - not a problem.  I understand dislike for assembly because traditionally
it's more difficult to implement and maintain.  

I'd still like to see it written in assembler though... :-)  My basic reason
for this is speed and space efficiency.  I don't know how to argue this...
let me think on it!

> =>> 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? :-]

Yikes!  No thank you!  I've still only got a little on IPC and processes, so
throw your ideas in *now*.  I've got most of the process management in the
new revision of the specs, but I'm drawing a blank on IPC and shared memory.

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

On second thought, you are correct.  When a child process allocates some memory
its parent should not have access to it.
 
> =>> 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.)

Hey neat!  I like that idea!  Persistent objects in the making...

How are we going to restrict these sorts of things?  It's easy to say a process
can have no more than, for example, 1 meg of non-virtual memory, but what if
it needs more than that?  Any suggestions?  Maybe its dependent on if the
process is a regular application, device driver, etc?

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

Maybe we shouldn't even mention block size.  Yes, its an implementation issue
(sorry) cause the 386 works nicely for virtual memory in 4k blocks. :-)
This makes resizing memory blocks *very* easy...of course, somebody mentioned
is the MemoryResize() capability even necessary?  Yes, it's nice but is it
necessary?

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

NULL doesn't have to be zero either!  Even C accounts for the fact that if NULL
is *not* zero, statements like the following will work:

	char *p;

	if (!p)			/* check for NULL p */
	    do something;

Ok, so make no assumptions about what the value of a NULL pointer will be,
just that there exists one single address which is considered NULL (invalid).

On most systems, NULL will be zero (Motorola and Intel).  On the Intel, a
long pointer (segment:offset) of all zeros will cause a protection fault.
Short pointers (just offset) have to be dealt with the the tasks themselves.

Oh...are we going to call them tasks or processes?  I prefer tasks because of
the term multitasking.  Not important... :-)

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

Great!  I was thinking that, just no time to add it to the specs.

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

Sounds like a good idea...but we'd need to clarify the concept of a message.
Any takers?

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

Ummm...actually, just a notation I made up.  I means the method called 'Down'
in the object called 'semaphore'.  Sorry to be unclear about that - it was just
to distinguish it from any other function we might have called '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.
> 
>    Assuming we have an object name space, they could be located and
> referenced like any other object (however that turns out to be.)

This all boils down to the IPC and shared memory issue...

> =>> Should we have spinlocks too?
> 
>    They probably wouldn't buy us a whole lot in a single processor
> system.

What if we did go to a multiple processor system?  Wouldn't they be
transparent to the user?  (Forgive if this is my mistake...little rusty)

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

I've found a file system (experimental) which is (1) extremely quick compared
to FFS, (2) very efficient with disk space, and (3) quite recoverable in the
event of a crash!  It's called the Viva File System, and was developed by a
couple of graduate students.  When I get the FTP site set up, I'll put the
docs I've collected so far on VIFS (VIva File System) in there.  What it comes
down to is that if the system goes down while writing a file, you will
probably lose the data which was being written (of course) but everything else
is secure.  I think it's an ideal file system for this environment, but we'll
have to see.  It's still experimental (but has been tested)...

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

Open foot, insert mouth.  Sorry, I wrote the section on libraries a couple of
months ago, and just stuck it in at the last minute.  I'll be more clear...

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

As long as the interface can be used by virtually any high-level language, it
*shouldn't* matter.  For example, no system call should use variable length
parameter lists [ void function(int a,...); ] because languages like Pascal
can't support them (very well).  

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

Maybe we could convice people to pry out that Mac ROM and stick in a more
generic one?  Hee hee.... :-)

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

One problem IBM PC/DOS has is no network support.  My brother makes a living
(full time) trying to keep a single small company's PC (both Macs and IBMs)
networked together.  This is a big job, and it shouldn't be.  I consider a
modem a "network device", and it should be treated any differently than a
FDDI fiber optic LAN.  Networking is the interconnectivity of computers,
not necessarily 50 office computers running from a single disk server (though
it could be), not my PC connected to a Cray-3 via fiber network (though I wish
it were :-), but maybe just one PC to another through a modem.

Hmmm...I may be putting my brother out of work here... :-(

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

No - I disagree.  Nothing is impossible...just because it hasn't been done yet
doesn't mean we can't do it.  There has to be a way to accomplish it!  I just
don't know what that is yet... :-)



Anyway, just some thoughts.  Hopefully everything will be a *lot* more clear
in the next version of the specs.  Look for it a FTP sites in your neighborhood
in the near future! :-)  Take care...hope to hear some replies!

				Dennis