Just can't get enough of that Moose!

[Gary D. Duzan]

=>
=>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 ... :-)
=>
   To be fair, the majority of the kernel itself will be doing hardware
twiddling, so there isn't as much cause to make it portable as the rest
of the system. It would, however, be a starting place for a port if it
were in an HLL.

=>> How are we going to restrict these sorts of things?  It's easy to say a pro
cess
=>> can have no more than, for example, 1 meg of non-virtual memory, but what i
f
=>> 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 th
e
=>process is irrelevant - of course the more memory thet is being used the more
=>paging but that;s life.
=>
   And we should restrict or limit anything with such a drastic impact
on system performance.

=>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.
=>
   We might be better off this way. We may want to consider a call that
maps a particular physical space into the virtual space, instead. This
would certainly have to be restricted.

=>> 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 relativel
y
=>"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)
=>
   Actually, under Mach, at least, the opposite is true: tasks are the
kernel-scheduled, heavyweight objects, while processes are scheduled
within the task.

=>> >    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 :-)
=>
   Doubtless true, but we should probably decide what we want to do
before defining terms. Otherwise, we would probably end up with a
complete OS dictionary.

=>> > =>> 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.
=>
   But if there is only one processor, who is going to release the lock
while you are spinning on it? You would end up spinning until the next
context switch, at least, wasting the rest of the time slice. Of course,
if you mean spinning on a hardware event, that is different.

=>Next question: Do we have some notion of transactions, atomicity etc.
=>(a 'la database systems)
=>
   Not in the kernel, I think (unless we want exactly-once IPC semantics)
but we should be able to add them later.

=>I was commenting on the choice of standards which (I think) were Unix type
=>standards. I (probly) am wrong here.
=>
   What do you mean by "Unix type standards"?

   I'll put together my ideas on processes an IPC and post them when I
get a chance.

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