Re: virtual kernels, syscall routing, etc.

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Fri Nov 28 2008 at 13:50:01 +0000, Andrew Doran 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?

That's exactly the kind of detailed nibbling I wanted to avoid for now,
as stated in the original email.  I am sure there will be unexpected
issues.  I am sure they can be solved.  Not doing it because of being
afraid of these challenges is not a very convincing reason to not do it.
If you're worried only about nibbly things, I take it as a good sign.

> > 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.

Nice bogus analogy.  What you are implying is analogous to the kernel
NFS daemon messages being routed through a userspace process and back
to the kernel.  The obvious difference is *handling* the request.

Now, again, what is the point of routing the calls through the kernel?

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

Define "gate"?