From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 20:59:32 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70D9A1065672 for ; Mon, 17 Mar 2008 20:59:32 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54F008FC17; Mon, 17 Mar 2008 20:59:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47DEDBB5.3040508@FreeBSD.org> Date: Mon, 17 Mar 2008 21:59:33 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Matthew Dillon References: <47DBC800.8030601@dir.bg> <47DD1FFF.6070004@FreeBSD.org> <200803170043.m2H0h2qO010175@apollo.backplane.com> <47DDCCC3.3020408@FreeBSD.org> <200803171838.m2HIcCii019146@apollo.backplane.com> <47DECF6D.9010806@FreeBSD.org> <200803172039.m2HKdux3020505@apollo.backplane.com> In-Reply-To: <200803172039.m2HKdux3020505@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jordan Gordeev , freebsd-hackers@FreeBSD.org Subject: Re: vkernel & GSoC, some questions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2008 20:59:32 -0000 Matthew Dillon wrote: > :I don't think there's an issue that needs solving, GCC has -nostdlib and > :-fno-builtin for precisely this reason. > > You are missing the point entirely. The point is to allow the vkernel > to use libc, aka allow it to be compiled, linked, and run as a normal > user process. What is your rationale for trying to bypass libc? Why > is it so important to you that the kernel retain all those conflicting > symbols when it takes literally just an hour of work to fix all the > conflicts? If your goal is to link vkernels with libc then by definition you are forced to resolve the namespace conflicts, but I don't see this as a necessary goal. A minimal standalone libkernel would do the same thing without requiring global changes to the kernel namespace, which would likely cause a lot of downstream angst for users of FreeBSD kernel code, providers of third party modules, etc. It seems pretty hard to justify that level of disruption. > :Anyway, I agree that this is the least of someone's worries during a > :hypothetical port of the dragonfly vkernel code. Just so everyone is > :clear, the scope of such an effort would not be "port the code", it > :would be "port the code and also finish it". > : > :Kris > > Jeeze, you make it sound like it is some incomplete mess when it is > far, far from that. The vkernel is complete, the APIs are complete. > It isn't finished in the sense that certain aspects of it, primarily > the 'disk' emulation, is not very well optimized, but you are doing > the work an extreme disservice by belittling it with undeserving > labels. What is the undeserving label? You agree that the code is not finished. In your previous emails you yourself gave a long discussion of changes that would need to be made to bring reasonable performance to various aspects of the vkernel code. I am not discouraging anyone from contributing to that work either in the context of the FreeBSD project or the Dragonfly project; on the contrary we are both pointing out that there is work that needs to be done by someone. Kris