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