Date: Sun, 28 Aug 2011 15:34:26 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: "K. Macy" <kmacy@freebsd.org> Cc: arch@freebsd.org Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc Message-ID: <alpine.BSF.2.00.1108281528210.8776@fledge.watson.org> In-Reply-To: <CAHM0Q_PS-Ev48p6GffdytNTR0e5Z9nvo=JW5GL_nU==FdLjvfQ@mail.gmail.com> References: <CAHM0Q_PS-Ev48p6GffdytNTR0e5Z9nvo=JW5GL_nU==FdLjvfQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1108281528210.8776>