elysium-developers

RE: [elysium-developers] IRQ handling

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

> I'm not sure that IRQ sharing can be done securely w/o the
> kernel. There is no reason that processes that need the bind to
> IRQ's, need to trust each other. How can we make sure that a
> process will pass on an IRQ event to others? (without using the
> kernel, that is). But the line can be drawn later.

I agree - we need some *trusted* software to handle the sharing of IRQs, but
IMHO it should be implemented as a trusted server process on top of the
kernel.

> As for IRQ latency: For keyboards, latency is not a big issue.
> However for things like sound cards and network cards it is more
> important. But all OS's have bottom-halfs (therefore some
> latency) and w/o the kernel saving state I don't see another way
> of doing it.

A - low-latency - solution could be:
* a device generates IRQ 7
* the running process is interrupted by interrupt 0x27 which traps to the
kernel
* the kernel calls the IRQ handler for IRQ 7 using a task state segment
* when the handler is done (this might be time bounded) it returns using
iret
* the kernel is resumed by the iret and the kernel issues an EOI
* finally the kernel returns to the formerly running process

This is merely a suggestion - comments?

/Kasper

Re: [elysium-developers] IRQ handling

[Adam L. <ag...@li...>]

On Sun, Feb 06, 2000 at 04:25:05PM +0100, Kasper Verdich Lund wrote:
> Since the Elysium kernel is a true micro-kernel it will not contain any
> drivers at all. I've been fiddling around with a keyboard driver - and a
<snip>

I'm not sure that IRQ sharing can be done securely w/o the kernel. There is=
 no reason that processes that need the bind to IRQ's, need to trust each o=
ther. How can we make sure that a process will pass on an IRQ event to othe=
rs? (without using the kernel, that is). But the line can be drawn later.

As for IRQ latency: For keyboards, latency is not a big issue. However for =
things like sound cards and network cards it is more important. But all OS'=
s have bottom-halfs (therefore some latency) and w/o the kernel saving stat=
e I don't see another way of doing it.

AGL

--=20
Smoking is one of the leading causes of statistics.

[elysium-developers] Protected Control Transfer

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

Greetings fellow developers,

Does anyone have any suggestions on how to provide (low-level) IPC
support? Basically what we need is one way of tranferring control to
another address space in a safe way. Most systems have a send/receive
mechanism that works either asynchronously or synchronously, but I think
it should be possible to remove those abstractions from the system. Any
opinions?

ExoPC/Xok - another exokernel system - allows the processes to define an
entry point to which other processes can make upcalls. The data
transmitted by such an upcall is the registers, plus an optional amount
of stack. 

/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

[elysium-developers] IRQ handling

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

Since the Elysium kernel is a true micro-kernel it will not contain any
drivers at all. I've been fiddling around with a keyboard driver - and a
text-mode video driver - but for the keyboard driver I need to hook IRQ 1.
I'm not quite sure how to do this in the most effective way.

On the kernel level I think every IRQ should have at most one user-level
handler - IRQ sharing should be implemented on top of the kernel. The
problem with an IRQ handler is the usual scheduling business, but under
Elysium things get worse. The Elysium kernel doesn't know how to save the
state of any running threads, since this is normally handled by the
individual processes. So the easy solution would be to revoke the CPU from
the process the usual way - by doing an upcall to the epilogue code in the
process (which handles saving the thread state) - and then giving the CPU to
the interrupt handler code (potentially in another process). I'm a bit
concerned about the delay between the actual IRQ firing and the invocation
of the handler - I think we'll have to come up with another solution.

Any suggestions? Alternative solutions?

/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

[elysium-developers] Demonstration disk image available

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

I've just uploaded a demonstration disk image, which shows some of the
capabilities of the latest kernel. It's not much, but it's available
from the file release section on the SourceForge project site
(http://sourceforge.net/project/?group_id=1260)

Regards,
Kasper

[elysium-developers] Kernel status and design revisited

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

To: Elysium Developers
Cc: ely...@li...
[sorry to those of you who receive this e-mail twice]

Since there has been quite a number of new developers during the last 24 hrs
I'll quickly outline the status and design of the project.

The role of the Elysium Kernel is to safely multiplex physical memory,
central processing unit(s), and i/o ports. The kernel should avoid
abstracting away any information or control - from the applications - which
isn't strictly necessary for protection.

1. Multiplexing Physical Memory
-------------------------------
To multiplex physical memory the kernel will hold a table of all physical
pages in the system. Each page may be marked as free or used. If it's marked
as used it will be protected by an associated guard (in form of a
capability). In addition to being free or used the page can marked as being
a page table or a page directory. I suggest these system calls for managing
the address space of a process:

/* set page directory of a process */
int sys_pd_set(uint32_t pd);

/* set an entry in a page directory */
int sys_pde_set(uint32_t pd, uint32_t pde, int e);

/* set an entry in a page table */
int sys_pte_set(uint32_t pt, uint32_t pte, int e);

Of course the process that uses these system calls will have to provide a
capability to access the pages it modifies, but the above mentioned system
calls is just to give you an idea of the current design. Comments are
welcome.

2. Multiplexing CPU(s)
----------------------
To multiplex the CPU we can represent the CPU as a (circular) vector of
quantums. Quantums in this vector should be protected by a guard - as it is
the case for physical pages. A process can allocate any number of free
quantums using system calls like:

/* allocate any available quantum */
int sys_quantum_alloc(int *quantum);

/* set quantum */
int sys_quantum_set(int quantum, pid_t pid);

Again this is just an outline. The scheduling is driven by the timer
interrupt, and works like this:

a) the scheduler picks a process to run
b) the scheduler does an upcall to an agreed-upon program point in the
process
c) the process picks a thread and restores it's stack and registers
d) once the timer interrupt fires the scheduler does another upcall to the
process, but this time at another entry point (also agreed-upon)
e) the process saves the thread context (stack and registers)
f) the process yields to the scheduler, which will start over at (a)

It's possible to build scheduler activations - or any thread scheduling
model - on top of this scheme.

3. Multiplexing I/O Ports
-------------------------
The Intel x86 architecture provides hardware ports - we'll need to multiplex
them in a safe and secure manner. One way would be to protect a range of I/O
ports by means of a guard. A process could then request access to a range of
ports, and if the capability it provides allows access to the ports the
kernel should flip some bits in the I/O permission bitmap of the process.

I know this is probably a bit too vague, but it's meant to be a starting
point for further discussion. Comments, questions, and the like are not only
welcome, but expected!

/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

[elysium-developers] Elysium kernel status

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

The current status of the Elysium kernel is that we've got a primitive,
yet working scheduler. I've succesfully run single-threaded processes on
top of the Elysium kernel and it seems to be working. Have a look at the
cpu.{c,h} files. The memory manager is up and running, but it lack
several fundamental things, such as capability protection (or something
similar) of physical pages. No work has been done on SMP stuff yet, but
jakob has agreed to do some work on it when his spare time permits it. 

/Kasper

[elysium-developers] Web-site update...

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

I've updated the web-site. It's still incomplete, but at least it
contains some useful information now. Please post your comments to this
mailing list, and feel free to update the web-site using ssh and scp.
The HTML pages can be found in:

/home/groups/elysium/htdocs/

Regards,
Kasper