User API still a goal?

[Michael Neumann]

Matthew Dillon wrote:
: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.
Ah okay, so it's no longer a goal.

: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
No, I was thinking about the messaged system calls and emulation of e.g.
Linux of FreeBSD system calls (in user-mode). As non-DragonFly native
binaries wouldn't know about messaged system calls, it was intended to
provide some kernel-protected (but user-mode) emulation layer, that
translates those syscalls to DragonFly native messages.
So an int 80h would call a function inside the user-mode process, which
then translates the syscall to a proper message call. Of course that
wouldn't be as fast as a direct system call.
Regards,

  Michael