vkernel & GSoC, some questions

[Matthew Dillon]

:
: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.

     Uh, well, each to his own but it sounds like pretty flimsy reasoning
     considering that major changes are made to the FreeBSD kernel every few
     months, particularly as related to APIs.  Frankly, adding a 'k' is
     not a big deal and holding up opaque third party modules as a reason
     for not evolving the system is pretty damn stupid considering the poor
     track record opaque black boxes have with regards to keeping up-to-date
     with open source software generally.  If they are driving the FreeBSD
     development process then you have a serious problem on your hands that
     goes beyond renaming a few functions.

     We had more issues changing the mbuf M_ defines to MB_ then we ever had
     changing the kernel printf to kprintf.  Not the least of which being that
     any issue that crops up due to a namespace change is immediately
     apparent simply due to the kernel failing to link or a module failing
     to load.  In a word: It's not the big deal you are making it out to be.

     In anycase, there is a lot more to running a UML/vkernel then just
     calling read() or write().  You only have to browse the platform/vkernel
     code to see all the places where there is a very high convenience factor
     to not having to hack around libc.  Your statement about using libkernel
     is short-sighted.

: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

    I'm a perfectionist.  No code is ever finished for me.  'Optimal' for
    someone like me is counting machine cycles and worrying about cache
    footprints, it's not the same definition that most other people use.

    I guess my problem is that you are holding this up as a red flag when
    it isn't even remotely close to being one.

					    -Matt
					    Matthew Dillon 
					    <dillon at backplane.com>