From owner-freebsd-arch@FreeBSD.ORG Sun Aug 28 14:34:27 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18CD61065679; Sun, 28 Aug 2011 14:34:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E95648FC22; Sun, 28 Aug 2011 14:34:26 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 769C546B1A; Sun, 28 Aug 2011 10:34:26 -0400 (EDT) Date: Sun, 28 Aug 2011 15:34:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "K. Macy" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Prefixing system calls to eliminate namespace collisions between kernel and libc X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 14:34:27 -0000 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