DragonFly kernel List (threaded) for 2006-09
Re: malloc/free/realloc will be renamed in the kernel
:Matt, I really think this is no good idea. I don't understand why you ar=
:e trying to link the kernel with libc in the first place anyways. The re=
:al kernel doesn't need libc, so why should the userland kernel need it? =
:What I see what's needed are three usermode kernel drivers: a console dr=
:iver, a usermode network interface driver and a signal handler. I don't =
:see anywhere that libc is really needed.
:Additionally, renaming malloc et all in the whole kernel just seems a big=
:, possibly even error-prone change, where it can be accomplished much mor=
:e easy and elegant with a linker script.
I thought it might be a bigger job then it actually was. It turned
out to be trivial. Sure there are going to be a few hicups, but nothing
that I would consider a big deal.
:I'm not arguing against a usermode kernel, yet I think that linking it wi=
:th libc is not the right idea. A kernel is self-contained anways, and th=
:e interfacing with the surrounding is done by drivers, so I don't see why=
: this should be different for a usermode kernel.
:Additionally, I think that having a usermode kernel and Xen support don't=
: exclude each other.
Well, if we don't link it against libc then developing pseudo devices
that interact with the real system would require considerably more
infrastructure. I kinda prefer having libc around so I can just write
that code as I would any application.
Lets consider the types of devices we want to support in the virtual
kernel. These devices must communicate with the real world:
* Console - Just use stdin and stdout
* 'External' Serial ports - Just use a couple of the real kernel's PTYs
* Disk - open/lseek/read/write/close
* Memory - mmap( ... MAP_ANON)
* Network - Just use the real kernel's TUN interfaces.
It would even be possible to using the new
bridging code to put a virtual kernel directly
on the real system's LAN.
Writing those devices should be a matter of a day or two on each one
with libc available. It will be so easy that I'm not even concerned
The hard part will be implementing the VMSPACE system calls, throwing
together the 'boot' code, and adjusting the code that manipulates process
contexts. There are also a few cases in the kernel itself where memory
pages are aliased which I haven't figured out the best solution for yet.