Just can't get enough of that Moose!

[Michael David WINIKOFF]

>    To be fair, the majority of the kernel itself will be doing hardware

Yes but I feel it can be encapsulated into a small module.

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

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

No. The obvious restriction is not to have virtual memory. If the user wants to
use more memory then s/he has then s/he pays the price in speed.
I don't see any point in providing virtual memory and then saying you can only
use it to a certain extant.

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

Sounds good.

>    Actually, under Mach, at least, the opposite is true: tasks are the
> kernel-scheduled, heavyweight objects, while processes are scheduled
> within the task.

Standards .. pick your favorite :-)

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

Hmm. But if we don't we could end up with a comunication problem. 
:-)

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

Whoops! You're right. (I was using spinlocks last year -- the work WAS on
a multiprocessor)

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

Doubt. These things are hard to add 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"?

Standards which in my mind are more in the world of workstations then personal
computers.

As I said - I'm rather vague in networks.

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


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