Re: virtual kernels, syscall routing, etc.

[Andrew Doran <ad%netbsd.org@localhost>]

On Fri, Nov 28, 2008 at 01:28:05PM +0200, Antti Kantee wrote:

> On Fri Nov 28 2008 at 10:50:09 +0000, Andrew Doran wrote:
> > On Thu, Nov 27, 2008 at 08:32:15PM +0200, Antti Kantee wrote:
> > 
> > > I've made the kernel nfs service (nfsd) run in userspace.
> > ...
> > > Now, the first idea is to simply add routing capability to the libc
> > > syscall stubs.  The fast path would still always trap into the kernel,
> > > but in other cases system calls could be handled by a process-to-process
> > > "trap", or in other words IPC. 
> > 
> > I don't like the idea of adding another layer of indirection. There is some
> > cross-over with NetBSD/usermode here. Another possibility is an emulation
> > type in kernel that redirects system calls to a listening process, but I
> > haven't given it much thought.
> 
> Please define "adding another layer of indirection".  I don't not see
> it as adding another layer of indirection, rather providing a parallel
> indirection/abstraction.

Maybe I'm assuming too much - tell us how you would implement it in the
system call stubs. Would you modify libc itself? How it would the assembly
output look in a PIC libc? Would changes be needed for every architecture?
What happens if a new system call is added in the future?
 
> What is the point of routing the syscalls through "the" kernel?
> That is exactly the kind of thing that should be avoided.  You can make
> everything slow by circulating messages around in places where they don't
> belong. The only exception is maybe in establishing a channel.

Permit me to be naughty for a moment:

  What's the point of putting NFS in userspace?
  That is exactly the kind of thing that should be avoided.  You can make
  everything slow by circulating messages around in places where they don't
  belong. The only exception is maybe in establishing a channel.

You have already got a ton of gates in place, right?

Thanks,
Andrew