Re: User API still a goal?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Michael Neumann wrote:
:> Hi,
:> 
:> I wonder whether the User API listed under goals, i.e. using message
:> passing for system calls instead of direct system calls (int 80), is
:> still a goal of DragonFly.
:> 
:> Are there any downsides of this approach not listed under the (very old)
:> goals section of the homepage?

    We are no longer persueing messaged system calls.  It turned out to
    be too difficult and too messy to do.  Basically the entire kernel
    would have had to have been rewritten to support it properly.

    I got as far as turning nanosleep into a messaged call and it was so
    messy that I stopped there, and later ripped it all out.

:And I wonder how the kernel-protected emulation layer is intended to
:work. Would that be a piece of code that can be registered for a
:specific software interrupt (e.g. int 80h)? That is, in case of x86, the
:kernel would install an interrupt handler for int 80 into the IDT for
:the process, and this interrupt handler is a user-mode routine.
:This user-mode routine will then translate the request into a message
:call (using another interrupt vector than int 80h or another syscall
:mechanism).
:
:Regards,
:
:   Michael

    Not sure what you mean here.  Do you mean the vkernel support?  An
    emulated int 80h is caught and passes the register context back to
    the managing (vkernel) process.  The vkernel then does the rest.

    It actually works in reverse, sorta.  Like this:

    vkernel -> vmspace_mcontrol(...) -> emulated environment
		(pass control to emulated environment)
					run
					run
					run
					run
    vkernel <- ----------------------	int 80h
		(pass control back to vkernel)

    It works the same for page faults, system calls, and other things
    that the emulated environment can't handle itself.  In the case of
    page faults the real kernel can sometimes handle the fault and not
    have to return to the vkernel.

    A signal sent to the vkernel will break it out the emulated environment
    as well, which is how the vkernel implements its scheduler.

    With a SMP vkernel build a LWP thread for each 'cpu' and can pass
    control to the emulated environment on multiple cpus at once.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>