Re: User API still a goal?

[Michael Neumann <mneumann@xxxxxxxx>]

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