Re: malloc/free/realloc will be renamed in the kernel

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

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

    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
    about them.

    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.

						-Matt