[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: virtual kernels, syscall routing, etc.
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?
Main Index |
Thread Index |