From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 20:40:07 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 827451065670; Mon, 17 Mar 2008 20:40:07 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 46FA08FC14; Mon, 17 Mar 2008 20:40:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.13.7) with ESMTP id m2HKduG5020506; Mon, 17 Mar 2008 13:39:56 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m2HKdux3020505; Mon, 17 Mar 2008 13:39:56 -0700 (PDT) Date: Mon, 17 Mar 2008 13:39:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200803172039.m2HKdux3020505@apollo.backplane.com> To: Kris Kennaway 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> 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:40:07 -0000 :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? :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. Do you think that hypervisors are magically more efficient? Do you honestly believe that having to spend thousands of man hours writing one hack after another to make windows run well on VMWare is the proper development path? Do you really want to load opaque black boxes into FreeBSD's kernel which you have no control over? If you have some disagreement about the APIs used to implement the emulation then I am all ears. Is there something you don't like about the new mmap() feature? Is there something you don't like about the new vmspace_*() system calls? I'm a perfectionist but my work output is also limited. You are quite welcome to help improve our projects, but if you are expecting me to dedicate my entire life to 'improving' one single aspect of our project, the vkernel in this case, just to satisfy some twisted idea of completeness, it isn't going to happen. Code submissions are always welcome in our corner of the woods. -Matt Matthew Dillon