Prefixing system calls to eliminate namespace collisions between kernel and libc

[Robert Watson]

On Sun, 28 Aug 2011, K. Macy wrote:

> NetBSD long ago made this change as well. and for linux this may always have 
> been the case. Linking POSIX programs against parts of the kernel can 
> actually be done just by mangling things during dynamic linking, so doesn't 
> require the above, but it is certainly easier and more portable with the 
> above. Ultimately I would like my userspace network stack to be able to run 
> on windows as well. I don't think that I have the same flexibility there 
> with regards to linker scripts.

This seems pretty reasonable to me.  The reason I have considered similar 
changes in the past was the additional case you cite above: it makes it a bit 
easier to link a POSIX-based application directly into the FreeBSD kernel. 
As you point out, we could address that problem by teaching our kernel linker 
about different namespaces, handling mangling at load-time.  However, I think 
your approach works better as it avoids the need for "special" linkage.

There are a number of other potential areas of collisions that I'm aware of:

(1) libc-like interfaces such as malloc(9), which differs observably from
     malloc(3); libkern is mostly the same (and often literally the same code)
     but it could be other tweaks are required.  One fix here is to move to
     calling our kernel malloc kmalloc(9).  I see that as a somewhat larger
     change though, but perhaps less pressing as it's a very small number of
     collisions that we can handle explicitly.

(2) Other libraries that are derived from or share code with the kernel, but
     that might have interfaces with different semantics.  libsbuf and libbsm
     come particularly to mind, but there might well be others.  I think these
     can be fixed without too much trouble, and I'm happy to ponder the libbsm
     case myself.

(3) The kernel RPC code, which uses interfaces very much like userspace.  It
     could be that, in fact, they are the same APIs in userspace, but we will
     need to check as that's a non-trivial part of the symbol namespace.  This
     might be particularly relevant if you want userspace RPC code to be able
     to use your userspace instance of the network stack.  Possibly prefixing
     'k' in front of a lot of things would be useful here as well...

In general, consider me supportive of this cleanup -- it would make a number 
of things I'd like to do much easier.  Abstractly, it seems like we should 
treat the two namespaces as being completely independent (hence thoughts of 
symbol mangling in the linker), but in practical terms it should be quite 
useful and might prevent having to solve much harder problems.

On a semi-related note: it would be nice if the kernel had an explicit symbol 
export list for kernel symbols, as our modules themselves support.  This would 
make it easier to discourage third parties from using "less public" interfaces 
in kernel modules, which tends to make those kernel modules fragile in the 
presence of regular baseline development...

Robert