Re: vkernel & GSoC, some questions

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"

_______________________________________________
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"