Just can't get enough of that Moose!

[Michael David WINIKOFF]

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

That's me -- sorry.
I at one stage sent a message to the mailing list b4 it was correctly setup
and had the message bounced.

Since I didn't have another copy of the message of the message I remailed the
bounce.

OH BTW - IF ANDREASA IS READING THIS CAN HE PLEASE REPLY TO ME?
I'VE HAD A NUMBER OF MESSAGES THAT I'VE SENT DIRECTLY TO HIM RETURNED TO ME
AFTER A WEEK


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

Traditionaly?!
Some people do seem to be able to handle assembler as well as high level
languages.
Us mortals however find HLLs a lot easier to use.

Oh - and you haven't mentioned portability ... :-)

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

The single counterargument I have is that efficiency in many cases is more a 
function of the algorithm then of the code -- a good paging algorithm in, say,
smalltalk will give better system performance then a bad one in assembler.

Of course this is not allways true and code size can occaisonly be reduced
by using assembler -- usually this is only becuase the compiler doesn't 
bother taking out library functions that aren't used.

Note that on RISC it is hard to do better then a good compiler ...

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

SHOCKHORRORFEARLOATHING :-)

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

Hmmm. If we have virtual memory then the amount of physical memory used by the
process is irrelevant - of course the more memory thet is being used the more
paging but that;s life.

There is a problem with MEM_PHYSICAL -- the simplest solution is to only 
allow device drivers to use the flag and not place a limit -- we are working 
under the assumption that device driver writers know what they're doing.

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

My feeling is that tasks are "lighter" things whereas processes are relatively
"heavy". If we are only going to support one form of process/task/thread then
the name doesn't really matter.

Process seems to be the more commonly used (at least in the Un*x world)

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

Hmm. I think I detect the need for a glossary of terms :-)

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

Message: something that is sent to an object -- sort of like a call.
You could define it by it's operations:
	send(objectid,data)
	recieve(data,&sender's-id)

The open issue is how to comunicate the data -- if it's a few bytes all's well
for larger data you need to either set up a shared address space region or
copy the data.

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

Hmm -- shouldn't this be language dependant or are we just using a generic
notation for design purposes?

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

Yes.

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

No they would -- a semaphore requires a system call whereas a spinlock doesn't.
This makes spinlocks significantly faster.

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

I'm not sure what exactly you mean.

Some things should be transparent to the user -- if two processes try to 
access a "file" simulatneuosly the system should do something sensible.

Spinlocks/semaphores are the mechanism used by the system to co-ordinate so 
this "something sensible" happens.

They are also used for writting applications that involve multiplt cooperating
tasks/processes.


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

Next question: Do we have some notion of transactions, atomicity etc.
(a 'la database systems)

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

And after all that work Micro$oft put into Windows ... :-)

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

I was commenting on the choice of standards which (I think) were Unix type
standards. I (probly) am wrong 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. :-(

Huh? Why? 

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

That's the spirit!!!!


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.