vkernel & GSoC, some questions

[Matthew Dillon]

:>     Well, I don't think I would agree with your assessment but,
:>     particularly, the way vkernels are implemented in DragonFly is NOT
:>     in the least disruptive to kernel source.
:
:I was referring to the decision you made to rename all of the kernel 
:functions that conflicted with libc functions so that vkernels could be 
:linked against libc.
:
:Kris

    Huh. Well, that's about the last thing I would have thought would be
    considered disruptive to the kernel source.  Everyone liked those changes.  
    malloc -> kmalloc, printf -> kprintf, and so forth... just not a big
    deal and it allowed numerous special cases in the header files dealing
    with prototype conflicts to be removed in addition to allowing vkernel's
    to link against libc.  Not only that but it removed conflicts against
    GCC builtins (which have their own ideas about what '%' features are
    valid and what are not) and properly separated kernel functions like
    sprintf to ksprintf, especially considering that the kernel version of
    sprintf does not support everything that the libc version does.

    For that matter you might as well throw in the system call function name
    changes.  Instead of the actual system call in the kernel being called
    'read()' it is now called 'sys_read()', so as not to conflict with
    'read()'.  That turned out to be a major positive clarification of
    the source code that made syscall entry points completely obvious to
    even non kernel programmers trying to read and understand it.

    All in all, it was a very good move for the project and I would
    strongly recommend that FreeBSD do the same thing.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>