Just can't get enough of that Moose!
Gary D. Duzan
duzan@udel.edu
Mon, 22 Feb 93 19:46:14 -0500
=>>
=>> 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.
=>
In an object system, IPC is going to be vital.
=>> 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 proce
ss
=>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?
=>
System per-object quotas?
=>Oh...are we going to call them tasks or processes? I prefer tasks because of
=>the term multitasking. Not important... :-)
=>
How about objects? It's an object-oriented system, right?
=>> =>> I favor a simple interrupt routine that "converts" an interrupt to a me
ssag
=>> e.
=>> =>> Of course some interrupts WILL need to be handled by an interrupt routi
ne 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?
=>
Well, if what we have thought of as a processes/task is going to be
an object in our system, then a message (RPC call) is an object method
call (implementation details aside.)
=>> =>> > 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 ju
st
=>to distinguish it from any other function we might have called 'Down'.
=>
I thought I said that. :-)
=>> =>> 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...
=>
Yep.
=>> =>> 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)
=>
Actually, spin locks don't need to bother with the OS at all. They
are a brute-force lock mechanism that can be implemented in any old chunk
of shared memory. We shouldn't have to worry about them for a while.
=>Hmmm...I may be putting my brother out of work here... :-(
=>
I don't think he need worry just yet. :-)
=>> =>> (2) We need to have a configuration facility to make installation of ne
w
=>> =>> 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 ye
t
=>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... :-)
=>
Well, I work in PC support and administration, and with IRQ, I/O,
RAM, ROM, and DMA settings and conflicts to deal with, the OS is
irrelevant. Of course, once the hardware is sorted out and you have
the numbers, we should make it easy to configure the OS.
Gary Duzan
Time Lord
Third Regeneration
Humble Practitioner of the Computer Arts