Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Mar 2008 13:39:56 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Kris Kennaway <kris@FreeBSD.org>
Cc:        Jordan Gordeev <jgordeev@dir.bg>, freebsd-hackers@FreeBSD.org
Subject:   Re: vkernel & GSoC, some questions
Message-ID:  <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>

next in thread | previous in thread | raw e-mail | index | archive | help

: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 
					<dillon@backplane.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803172039.m2HKdux3020505>