Re: NOSECURE removal

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

	(moved from the submit list)

:Cool! 8-) 8-)
:
:I and Jeroen were planning on doing a lot of cleanup work.  Up to the 
:coming December or so, I am going to focus mostly on backporting ideal 
:functionality from the three BSDs and Linux; and also bring in bug fixes.
:
:Another thing lined up, and I think also Jeroen is interested in, is 
:doign a KAME sync the Right Way(tm).  If you see the way the KAME code 
:has been integ'ed in FreeBSD, it is butt-ugly (no offense).  This will 
:be a big project to work on, but once it has been achieved, doing syncs 
:with KAME will become WAY easier.
:
:Cheers.
:
:-- 
:Hiten M. Pandya

    This sounds like an excellent excuse to rework the kernel network and
    module APIs and to start to develop a userland kernel module interface
    for things like VFS's, network stack components, etc.

    It occurs to me that a great deal of the kernel module management
    operates almost as though the module were a process, but the kernel
    module design has always been a pretty bad hack.  It seems to me that
    a kernel process, where you actually 'run' a program in the
    kernel almost the same way you run a user program in userland, might
    be a better approach.

    Think of it kinda like older non-MMU operating systems like the Amiga,
    where all programs basically share the same address space.  It would be
    very easy to give the kernel the capability to 'load' an ELF program
    into the kernel's address space, capable of sharing other resources
    loaded into the kernel's address space (e.g. like amiga programs,
    amiga shared libraries, and the Amiga's resident program feature).
    I'm not talking about the current kernel loadable modules interface...
    what a piece of junk that is... I'm talking about a real in-kernel
    user-executable thread/process model.

    In anycase, doing something like this would not be difficult.  The
    kernel would still track the program's resources, it would just be that
    the program happens to run in supervisor mode and uses KVM instead of
    user virtual memory.

    But consider the implications... things like KAME could be ported as 
    independant, standalone entities which you 'run', without any loss of
    performance.  You could also create simulated kernel environments which
    are really just a user process for testing, you could create virtual
    machines, and so on and so forth.  We would eventually be able to make
    nearly all non-hardware-specific subsystems in the kernel operate 
    this way.  It would enforce very good discipline on kernel subsystems
    because they would not be able to directly tie-in to kernel global
    variables and such.  APIs would have to be developed for the major
    interfacing.

    Ok, call me crazy, but...

					    -Matt
					    Matthew Dillon 
					    <dillon@xxxxxxxxxxxxx>