gemini-developers

Re: [gemini-developers] Re: Gemini

[Guido de J. <gu...@dd...>]

A quick reaction:

> A process is a collection of tasks. A task can be described as a tuple
> (A, P, E) where A is an address space (which may be shared with other
> tasks), P is the prologue code offset, and E is the epilogue code
> offset. 

Each task belongs to one and only one process?
The collection of tasks belonging to a process all share the same address
space? But not the upcall points?

> A task can be scheduled by entering it in a CPU quantum vector. When
> the CPU wants to schedule the task it does an upcall to the specified
> prologue code offset. The CPU quantum consists of a number of clock
> ticks (10 or so) and when no more ticks are available the timer
> interrupt handler revokes the CPU from the task by pushing the current
> user EIP on the user stack and upcalling to the epilogue code
> offset. The net effect is that from the task's point of view it
> appears as if the epilogue function was called. The epilogue code can
> then save the state of the registers and yield. The number of clock
> ticks spent in the epilogue function is recorded, and the task will
> pay for any excess time by forfeiting some of the clock ticks in it's
> next quantum. 

IMHO there's one drawback to this approach: the high number of supervisor mode -
user mode switches. The task normally runs in user mode. Then, a timer interrupt
will trigger a switch to supervisor mode. The upcall to the epilogue will cause
a switch back to user mode and the "yield" system call forces a another switch
into supervisor mode. Finally by upcalling the prologue of the next task the
CPU will run in user mode again.

We'll have to find an optimum for the timer frequency and the quantum size, in
order to minimize the number of task switches, yet maximize the time a task
has to actually do something useful.

> Threads are handled internally by the tasks - the kernel knows nothing
> about threads. Note that efficient user-level thread packages can be
> built on top of this scheme since the nucleus notifies the task of CPU
> revocation.

Yes, similar to the scheduler activations.

> A process can register a task that handles incoming communication
> requests (in the form of protected control transfers). If process A
> wants to transfer control to process B it does so by doing a system
> call - PCT - which basically jumps to the new task. It should be noted
> that the registers not used as arguments to the PCT are kept, so that
> some basic data can be transferred to the receiver side. The detailed
> description is as follows:
> 
>  * process A (or more precisely one of it's tasks) puts the pid of
>    process B into register eax, and any extra data into the remaining
>    general purpose registers.
>  
>  * process A saves any thread information - such as registers and
>    stack pointer.
> 
>  * process A uses the system call PCT, which traps to the nucleus.
> 
>  * the nucleus allows the PCT handler task of process B to run in the
>    current CPU quantum using the remaining clock ticks. 
> 
>  * when no more quantum clock ticks are available the nucleus upcalls
>    to the epilogue code of the PCT handler task.
> 
>  * the nucleus schedules the task specified in the next quantum - it
>    doesn't return to process A.

So, for IPC a process must register a special task and thus a special upcall
point? All tasks belonging to one process share the same PID? Also the task
doing the PCT is blocked?

> IRQ handlers are also just tasks, but since these can be called - by
> hardware - at arbitrary times we cannot rely on tasks to save
> registers before doing the PCT. A solution is to let the IRQ handler
> return to the 'calling' task.

Actually, "normal" tasks will never have the chance to save register values, but
must be able to rely on the IRQ handler to do that for them.

> To improve performance a task can also be run in a small address
> space. Small address spaces are 4Mb (one page directory entry) address
> spaces, which are mapped into all (large) address spaces. The
> protection is handled by means of segmentation not paging. The nucleus
> allocates a fixed number of small address spaces, and allows processes
> to put tasks into the slots. One good use of this feature is to put
> most IRQ handler tasks into small address spaces. Whenever an IRQ
> fires no context switch is needed.

The number of small address spaces is dependent on the size of physical memory,
as they will generally not be swapped out to disk?

Guido

[gemini-developers] Re: Gemini

[Kasper V. L. <ve...@da...>]

Guido de Jong <gu...@dd...> writes:

> From the email I have been receiving I understand that you have a lot of ideas
> for the Gemini Nucleus. I'd really like some documentaion on them, if available
> of course. Currently I get the feeling that the ideas only exist inside your
> head. Please share them!

I've done some more code on the kernel, but I decided to stop coding
and start documenting. I've been discussing the process/task/thread
situation with Jakob, and I'll be documenting it today. We're not
quite sure about the terminology, but the functionality is - IMHO -
quite cool.

A process is a collection of tasks. A task can be described as a tuple
(A, P, E) where A is an address space (which may be shared with other
tasks), P is the prologue code offset, and E is the epilogue code
offset. 

A task can be scheduled by entering it in a CPU quantum vector. When
the CPU wants to schedule the task it does an upcall to the specified
prologue code offset. The CPU quantum consists of a number of clock
ticks (10 or so) and when no more ticks are available the timer
interrupt handler revokes the CPU from the task by pushing the current
user EIP on the user stack and upcalling to the epilogue code
offset. The net effect is that from the task's point of view it
appears as if the epilogue function was called. The epilogue code can
then save the state of the registers and yield. The number of clock
ticks spent in the epilogue function is recorded, and the task will
pay for any excess time by forfeiting some of the clock ticks in it's
next quantum. 

Threads are handled internally by the tasks - the kernel knows nothing
about threads. Note that efficient user-level thread packages can be
built on top of this scheme since the nucleus notifies the task of CPU
revocation.

A process can register a task that handles incoming communication
requests (in the form of protected control transfers). If process A
wants to transfer control to process B it does so by doing a system
call - PCT - which basically jumps to the new task. It should be noted
that the registers not used as arguments to the PCT are kept, so that
some basic data can be transferred to the receiver side. The detailed
description is as follows:

 * process A (or more precisely one of it's tasks) puts the pid of
   process B into register eax, and any extra data into the remaining
   general purpose registers.
 
 * process A saves any thread information - such as registers and
   stack pointer.

 * process A uses the system call PCT, which traps to the nucleus.

 * the nucleus allows the PCT handler task of process B to run in the
   current CPU quantum using the remaining clock ticks. 

 * when no more quantum clock ticks are available the nucleus upcalls
   to the epilogue code of the PCT handler task.

 * the nucleus schedules the task specified in the next quantum - it
   doesn't return to process A.

IRQ handlers are also just tasks, but since these can be called - by
hardware - at arbitrary times we cannot rely on tasks to save
registers before doing the PCT. A solution is to let the IRQ handler
return to the 'calling' task.

To improve performance a task can also be run in a small address
space. Small address spaces are 4Mb (one page directory entry) address
spaces, which are mapped into all (large) address spaces. The
protection is handled by means of segmentation not paging. The nucleus
allocates a fixed number of small address spaces, and allows processes
to put tasks into the slots. One good use of this feature is to put
most IRQ handler tasks into small address spaces. Whenever an IRQ
fires no context switch is needed.

/Kasper

-- 
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 5342.220            | Phone: (+45) 8942 5646
Email:  ve...@da... | WWW: http://www.daimi.au.dk/~verdich

[gemini-developers] Micro-kernel based exokernel?

[Kasper V. L. <ve...@da...>]

To: Lars Arvidson
Cc: gem...@li...

> You have stated that gemini would be a 'micro-kernel *based* exokernel'.

Yes, I have.

> Is this not a contradiction? It is my understanding that a micro-kernel
based
> architecture implies privileged user-level serves (pageing, fs).

You're right in the sense that the basic idea behind a micro-kernel is to
take *privileged* code from the kernel and put it into *privileged*
user-level servers. This is good for fault-isolation and extensibility, but
it doesn't necessarily provide the level of flexibility an exo-kernel
provides. The idea behind the Gemini Nucleus is to take the exo-kernel
principles -- especially 'do not enforce any abstractions that aren't
strictly necessary for protection' -- and apply these to a micro-kernel. The
result will be a micro-kernel that only protects the lowest levels of the
hardware -- such as I/O ports and physical memory -- and a set of privileged
servers that protects higher (more abstract) levels of the hardware -- such
as disk blocks (which basically is an abstraction built on top of I/O ports,
physical memory, and disk hardware) and network.

It's vital to realize that the Gemini Nucleus is nothing but the
micro-kernel itself. In itself it does conform to the exo-principles, but it
doesn't guarentee that the privileged servers Sir General Public builds on
top of it conform to the exo-principles. It's easy to imagine building
standard filesystem servers on top of the Gemini Nucleus instead of building
a more 'exo' -- and IMHO more interesting -- disk block server that protects
the disk blocks using something like UDFs (untrusted deterministic
functions).

> Could you define 'micro-kernel *based* exokernel'?

A better term would probably be something like 'an exo *operating system*
based on a micro-kernel'.

/Kasper

-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich


----- Original Message -----
From: "Lars Arvidson" <d4...@dt...>
To: "Kasper Verdich Lund" <ve...@da...>
Sent: Tuesday, March 28, 2000 1:56 AM
Subject: SV: [gemini] Welcome!


> Hi Kasper!
>
> It would be fun to participate in the gemini-project. I've been following
the elysium-developers discussion for some time and I've found it
interesting. My primary interest is in kernel philosophy, architecture and
implementation. I'm not very interested in implementing higher-level
operating system stuff such as gui, shells or os tools.
> I do not know if I'll be able to devote a lot of time on the project as
I'm about to start working next week, but I'll try to be as active as
possible.
> I have some experience with low level c coding in gcc.
>
>
> My user id at sourceforge is d4arvid.
>
> /Lars
>
>
> ----- Ursprungligt meddelande -----
> Från: Kasper Verdich Lund <ve...@da...>
> Till: <d4...@dt...>
> Skickat: den 27 mars 2000 20:14
> Ämne: [gemini] Welcome!
>
>
> > Hi,
> >
> > Welcome to 'gemini-developers'. If you want to be on the SourceForge
> > developer list (and get write-access to the CVS repository) I need your
> > SourceForge login.
> >
> > Kind Regards,
> > Kasper
> >
>
>

Re: [gemini-developers] Initial CVS import complete

[Kasper V. L. <ve...@da...>]

Guido de Jong wrote:
> Little update:
> - It does boot

It's supposed to :-)

> - It really doesn't do anything besides throwing the NMI.

No, not yet -- but it shows that the exception handling stuff probably
has survived the trip from the Elysium kernel to the Gemini Nucleus.
 
/Kasper

Re: [gemini-developers] Initial CVS import complete

[Guido de J. <gu...@dd...>]

Kasper Verdich Lund wrote:
> 
> Hi,
> 
> I've just imported the initial source code into the Gemini Nucleus CVS
> repository. Use
> 
> cvs -d[your_login]@cvs.gemini.sourceforge.net:/cvsroot/gemini co nucleus
> 
> to check out the source code. Please try to compile (perhaps even boot)
> it right away.

Little update:
- It does boot
- If you get an Non Maskable Interrupt exception, it still does boot. It
just isn't very pretty... (why not having an int3?)
- It really doesn't do anything besides throwing the NMI.

Guido

Re: [gemini-developers] Initial CVS import complete

[Guido de J. <gu...@dd...>]

Kasper Verdich Lund wrote:
> 
> Hi,
> 
> I've just imported the initial source code into the Gemini Nucleus CVS
> repository. Use
> 
> cvs -d[your_login]@cvs.gemini.sourceforge.net:/cvsroot/gemini co nucleus
> 
> to check out the source code. Please try to compile (perhaps even boot)
> it right away.
 
Cool!!!
If it compiles, I'll even try to boot it!

Guido

[gemini-developers] Initial CVS import complete

[Kasper V. L. <ve...@da...>]

Hi,

I've just imported the initial source code into the Gemini Nucleus CVS
repository. Use

cvs -d[your_login]@cvs.gemini.sourceforge.net:/cvsroot/gemini co nucleus

to check out the source code. Please try to compile (perhaps even boot)
it right away.

/Kasper

[gemini-developers] Yep, it works...

[Guido de J. <gu...@dd...>]

Merely wrote this as a test.
Also put up a tiny webpage, just to be rid of the SF default page.

Guido