DragonFly kernel List (threaded) for 2003-08
Re: NOSECURE removal
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.
> :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
> 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
> Ok, call me crazy, but...
> Matthew Dillon
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.