Re: NOSECURE removal

[Robert Garrett <rg70@xxxxxxxxxxxxx>]

Matthew Dillon wrote:

> (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>
Hmm, I was under the impression this is the direction we were going already,
with the messaging being the interface between kernel application land,
and the kernel supervisor.

rob