exec server idea

Hi all,

I don't like the fact that this list is going to be silent.

I guess a lot of work has been done since 1.3.2 is out, when will
1.3.3 come?

I'd like to start a discussion about a exec server again.

I think a exec server would be reasonable.

It could:

- help to implement different formats for executables (yeah this can
be done in the lib but...)

- transparently execute programs on other machines or extention boards

- transparently solve the problem of more or less trusted programs
without having the shell maintain a database for this (I find this
solution very difficult and it will grow and complicate all the
shells.)

- also serve a proc file system with very few help from the kernel.

- remove signal handling primitives from the kernel

- handling of shared libs could be simplified (It would even be
possible to have a exec server which can "run" a Makefile. This way a
directory containing the source would have a transparent view as a executable...)

- could eventually "execute" trusted code inside of the kernel (like
isr primitives, other schedulers etc.) in a very simple manner.

How about the following interface:

- A exec server would be mounted over say /bin and knows one or more
places where to look for executable files.

- to run a program we'll have to tell it which program, the argument
line and our current name space.

This could be done by open a file (the name of the executable) for
write a line of arguments, then write the mount table, eventually write
the current content of /env/#. Then write "run". Probably we should
separate the parts by keywords like this:

arguments:
<here goes the argument line>
mount table:
<here goes, what fstab gives you>
run!

- now the server could fork. Insert the new process in it's proc file
system and in the child process set it's id to the one of the user,
load the executable, set up the mount table and execute the actual
program.

- the shell, or whatever "lauched" the programm could know read the
process number from the file and later the exit code.

- to notify anything just write "signal: <signalname>" and have the
exec server responsible for the rest. (Or write this to the
appropriate file in the proc file system.)

- a close (or at least a disconnect) on the file would have a meaning
of kill for foreground processes and nothing for background.

- signal handling could be really simple. It would not even need help
from the kernel. Just have a thread in each program (lauched silently
before the main is executed) listning on a port and have the exec
server dispatch the signals to this port. Only for a unconditional
kill of a thread a kernel help would be needed. But this doen't work
by now anyway.

BTW: (If you don't believe this: take the semasrv, remove the
unqueueing of a pending request in the abort, then start semasrv and
the sematest, wait 23 seconds and try to kill the hanging sematest.)

- the signal serving thread could also take over the responsibility
for semaphores (in a way may first attempt of the implementation of
the semasrv was made -- this happend not to work but appearantly
because of the debugging code I've thrown in) such to spare two
context switches on semaphore operations.)

- to run code in the kernel, the server would require a page from the
kernel, relocate a object in this page (using the map of the kernel)
and give the kernel an address to start. This could even mean to
chance the complete kernel at run time ;-).

- I guess even the permission code could be removed from the kernel.
Just have the M_CONNECT identify the responsible "securety server"
here the exec server and ask it for id's on a M_CONNECT.

The longer I consider the question, the more ideas I get. But I think
this should be enough for now.

Any thoughts wellcome.

Joerg

-----------------------------------------------------------------------------
Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de
Rietzstr. 32b |
01139 Dresden |
Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8

WWW: <a href=http://www.inf.tu-dresden.de:~jw6/top.html> (click here) </a>
Received on Mon Jan 9 08:37:21 1995