Virtual kernel progress update

[Matthew Dillon]

    There are still a ton of things that I have to get working, but the
    VKERNEL now boots through to the point where it tries to vmfork() the
    init process. 

test28# ./kernel.debug -m 64m
Copyright (c) 2003, 2004, 2005, 2006, 2007 The DragonFly Project.
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
DragonFly 1.7.0-DEVELOPMENT #179: Sat Jan  6 11:55:07 PST 2007
    root at test28.backplane.com:/usr/obj/usr/src/sys/VKERNEL
real memory = 67108864 (65536K bytes)
avail memory = 62578688 (61112K bytes)
Segmentation fault (core dumped)

    I got the virtual kernel's page table (for its KVM) working.  The big
    ticket items left to do are as follows.   My goal is to be able to boot
    the virtual kernel through to a login: prompt on the console by the time
    we release in one week.

    * Adding TLS info to the vmspace context, since just about any program
      we might want to run needs TLS support.

    * Adding FP support, same reason.

    * Root filesystem support (it will be synchronous to begin with, i.e.
      not the fastest thing in the world.  It will just use read() and
      write() to a root filesystem image file for now).

    * We need a clock 'interrupt' to provide ticks to the virtual kernel.

    * Integrate exception handling, trap handling, and VMSPACE context
      switching.  <<< this is the hardest bit.


    The virtual kernel will not be truely useful until sometime after the
    release, probably about a month assuming I can get someone to build the
    pseudo network interface for me :-).  Making it truely useful requires:

    * Root filesystem support has to use DIRECTIO.

    * Root filesystem I/O has to be made asynchronous.

    * A Pseudo network interface has to be designed and built (so you can 
      login to the virtual kernel in some way other then the console).

    * Optimized page table invalidations.  At the moment they are ultra slow
      due to having to remove cached PTEs from the real kernel's page tables.

						-Matt