vkernel & GSoC, some questions

Kris Kennaway kris at FreeBSD.org
Mon Mar 17 20:59:32 UTC 2008

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.


More information about the freebsd-hackers mailing list