Hurd general design question

I had an observation; it seems that your support for native C++ is a
limiting factor to the Hurd. thing to remember is that I do not
have any experience in Systems. Second thing, forgive me if
this is not the right address for this subject.



My understanding is that one thing that hurts a multi-server microkernel
is the context switch. The need to store registers, stack points, copy
message buffers etc. Ideally a call of any sort would be just that a
function call. It seems to me that C++ prevents this, its ability to
reference any memory in its memory space, and read or write that memory
makes a simple function call to the kernel impossible.



The basic scenario is that program A calls kernel nonblocking function
B. Then right after invoking B program A modifies the data sent as
parameters to B. At this point function B has no way to guarantee the
correctness of the parameters passed to it. It must make a copy of
those parameters so that program A can not modify the parameters after
the function has validated them.



My general design question, what if you moved C++ to emulation? The
native language would then be a programming language that did not have
random access to the entire memory space. I'll use Java as an example.



In this scenario we'll have the same program A and function B except
this time we'll name the parameter C. Program A would create C,
initialize C and call B with C. B is called it locks C. This
makes it so that C can no longer be changed. Now B does not have to
make a copy of C but just needs to verify it. Seems faster.



Also it seems at this point you would not need a separate memory space
for each program. At this point a program only has access to the
objects it created or that were handed to it via reference. So if one
program never hands away the references to its objects then those
objects are in effect in their own memory space immune to the actions of
any other program.



Since there is only one memory domain the need for a context switch goes
away. In order to call through to the kernel there is no need to context
switch to get into the kernel's memory space. All the program would
need is a reference to an object defining the kernel. That object would
manage the references that make up the kernel. In reality the kernel
would be made up of any number of user level servers (wouldn't actually
be kernel level anything?).



I could go on with some other stuff, but I am not sure if I am crazy or
if this is even the right audience.



Mike Power

Hi,

Fri, Jul 25, 2008 at 11:45:36AM -0700, Power, Mike wrote:

I had an observation; it seems that your support for native C++ is a
limiting factor to the Hurd.
[]
My general design question, what if you moved C++ to emulation? The
native language would then be a programming language that did not have
random access to the entire memory space.

I'm not sure what you are proposing here. Is it to write the operating
system in some safe language, and run existing C (and other) software
only in an emulator?

As for writing an operating system in a safe language, that is certainly
an option, but not a panacea. Not using the hardware-provided protection
mechanisms indeed safes the overhead of context switches; but doing the
protection in software means *everything* runs slower in general -- in
most situations it's not a net win.

Anyways, there is a lot of existing research in this area -- it's not
like you are suggesting anything new here

As for running existing software in an emulation, this is totally out of
question for the Hurd. The Hurd, as the kernel of the GNU system, *must*
be able to run existing GNU and UNIX software well, not only as some
kind of second class citizen.

I could go on with some other stuff, but I am not sure if I am crazy
or if this is even the right audience.

Maybe the right audience; but I think it should be obvious that
esentially suggesting to throw everything away and work on something
completely different instead, is not likely to meet applause on a
project's developer mailing list -- even if it *was* a superior design
you are suggesting :-)

In any case, before making such suggestions, it would help a lot to get
familiar with the existing research in the area first

-antrik-