From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 21:16:52 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 37136106566C; Mon, 17 Mar 2008 21:16:52 +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 E99FC8FC20; Mon, 17 Mar 2008 21:16:51 +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 m2HLGaIA021002; Mon, 17 Mar 2008 14:16:38 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m2HLGZSf021001; Mon, 17 Mar 2008 14:16:35 -0700 (PDT) Date: Mon, 17 Mar 2008 14:16:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200803172116.m2HLGZSf021001@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> <200803172039.m2HKdux3020505@apollo.backplane.com> <47DEDBB5.3040508@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 21:16:52 -0000 : :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. Uh, well, each to his own but it sounds like pretty flimsy reasoning considering that major changes are made to the FreeBSD kernel every few months, particularly as related to APIs. Frankly, adding a 'k' is not a big deal and holding up opaque third party modules as a reason for not evolving the system is pretty damn stupid considering the poor track record opaque black boxes have with regards to keeping up-to-date with open source software generally. If they are driving the FreeBSD development process then you have a serious problem on your hands that goes beyond renaming a few functions. We had more issues changing the mbuf M_ defines to MB_ then we ever had changing the kernel printf to kprintf. Not the least of which being that any issue that crops up due to a namespace change is immediately apparent simply due to the kernel failing to link or a module failing to load. In a word: It's not the big deal you are making it out to be. In anycase, there is a lot more to running a UML/vkernel then just calling read() or write(). You only have to browse the platform/vkernel code to see all the places where there is a very high convenience factor to not having to hack around libc. Your statement about using libkernel is short-sighted. :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 I'm a perfectionist. No code is ever finished for me. 'Optimal' for someone like me is counting machine cycles and worrying about cache footprints, it's not the same definition that most other people use. I guess my problem is that you are holding this up as a red flag when it isn't even remotely close to being one. -Matt Matthew Dillon