Date: Mon, 17 Mar 2008 21:59:33 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Jordan Gordeev <jgordeev@dir.bg>, freebsd-hackers@FreeBSD.org Subject: Re: vkernel & GSoC, some questions Message-ID: <47DEDBB5.3040508@FreeBSD.org> In-Reply-To: <200803172039.m2HKdux3020505@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DEDBB5.3040508>