vkernel & GSoC, some questions
Julian Elischer
julian at elischer.org
Mon Mar 17 21:17:50 UTC 2008
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers
mailing list