NOSECURE removal

Robert Garrett rg70 at
Sun Aug 3 17:46:05 PDT 2003

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 at 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.


More information about the Kernel mailing list