vkernel & GSoC, some questions
dillon at apollo.backplane.com
Mon Mar 17 18:38:26 UTC 2008
:> 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.
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.
<dillon at backplane.com>
More information about the freebsd-hackers