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 "[EMAIL PROTECTED]"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
