From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 21:17:50 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 1DBCD1065670 for ; Mon, 17 Mar 2008 21:17:50 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id F210E8FC24 for ; Mon, 17 Mar 2008 21:17:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 17 Mar 2008 14:17:49 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 21A432D6011; Mon, 17 Mar 2008 14:17:49 -0700 (PDT) Message-ID: <47DEDFFF.8070703@elischer.org> Date: Mon, 17 Mar 2008 14:17:51 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 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> In-Reply-To: <47DEDBB5.3040508@FreeBSD.org> 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 21:17:50 -0000 Kris Kennaway wrote: > 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. It should be possible to make a libemul that provides just eh services needed, by doing the syscall() operation. actually, here's an idea.. a separate interpreter/exec/loader class that embeds some of the work into the kernel and uses syscalls that are designed exactly for the job required. (loaded as a .ko when needed.). who says it needs to run posix syscalls...? > >> :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 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"