Problem with Class-/Objectmanager

[cyr1x]

Hi,
I'm currently implementing a Class-/Objectmanager. Now i came across with a strange problem and I wanted to hear your opinions on this .
First the basic design:
I have a Classmanager, which obviously manages the classes. (creating classes, adding/deleting functions, ...). Then there're objects, which are just instances of the a specific class.

Now the problem is with the functions. How should I access them as they might be in different processes. I came up with this solutions:
- Copy the functions over to kernel space
-> Not good if the function relies on some other function/variables in the process
- Only allow functions from processes in kernel space
-> Not good in a microkernel
- Hold a context-structure of the process and switch to the process if the function is called
-> Sounds like the best solution, but this has a high Overhead.

Do you have any idea's ?

[trolly]

I unterstand your problem.
i'm programming a microkernel too.

to call a user process function (example: for driver), i use signals or message.
example:
when a process want to read the keyboard he send a message to the keyboard driver.
The kernel signal the kernel driver that a message was arrived.
When the keyboard process receive a signal, he read the command in the message box and make the correct action action, and send response to the "client".

[mrvn]

One design that fits this bets I think is the idea of donating time slices.

When calling a foreign function (function from another process) you would tell the kernel to switch processes but you would donate your timeslice(s) to the other process to run the function in. To implement this you would have to record in your task structure if a process is currently executing a foreign function. You would actualy need a stack or linked list to allow for recursive calls.

Note that unde i386 there are call gates and task gates that can do such switching in hardware. Although people seem to claim that software task switching is faster.

MfG
Mrvn

[senaus]

Hi,

- Hold a context-structure of the process and switch to the process if the function is called
-> Sounds like the best solution, but this has a high Overhead.

I think this is the only clean way of doing it, and sounds vaguely like the way I do it in my kernel.

I utilise a 'context stack' local to threads, which stores a reference to the process the thread is currently running in. This allows threads to weave in and out of processes as they make calls.

Sean

[cyr1x]

Thanks so far.

I have one another question.
Should I execute the functions with kernel rights or a full context switch to user mode. With kernel rights it would be easier to handle functions which are calling other function (i.e. accessing the stack), but you could do cli, sti, lgdt,lidt and other malicous code. How should I allocate a user mode stack which is accessible by all functions that are called by that one functions?(crappy question )

[senaus]

Should I execute the functions with kernel rights or a full context switch to user mode.

That depends - if the function is in a kernel module, then kernel mode; otherwise, if the function is written for a user mode process then there will be no benefits to running it in kernel mode (other than avoiding the context switch), and it will just be outright dangerous.

How should I allocate a user mode stack which is accessible by all functions that are called by that one functions?

Well, my solution to this is to require that all functions have a single parameter structure, which will contain all data that the function requires. The kernel, knowing the parameter size, can copy the parameters between address spaces. The kernel puts the parameters into a special memory region, and can avoid copying altogether if the function is in the same address space.

Sean