Date: Mon, 17 Mar 2008 14:17:51 -0700 From: Julian Elischer <julian@elischer.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: Jordan Gordeev <jgordeev@dir.bg>, freebsd-hackers@FreeBSD.org Subject: Re: vkernel & GSoC, some questions Message-ID: <47DEDFFF.8070703@elischer.org> In-Reply-To: <47DEDBB5.3040508@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DEDFFF.8070703>