- There may be a problem with the code deciding whether we can idle or
  we still have something to do in the kernel. Maybe we should count
  the number of activ kernel processes by ourselfs?

- dispatch_message_from_emulib() should not send a reply message when
  result of handler fn < 0

- can the L4 kernel debugger handle virtual != physical addresses?

- the L4 kernel debugger crashes if invoked with an ESP pointing into
  a non-mapped page

- with the "new" memory management architecture we take the long way 
  in nearly all situations when a page fault occurs. That means:

     client ---> service_thread ---> pager_thread ---> root_pager.

  That is a result of the assumption, that the page could be available
  already, but thats not true anymore. Maybe we should take a short cut
  and ask the root pager directly in all situations and skip the 
  redirection through the pager thread if we can.

- We still don't have exception handling within the kernel (for instance
  segmentation faults while accessing bad user areas resulting in an oops)

- l4_pager:
     return sequence after a bad access modified. 
	There are processes, which ignore segmentation faults. That
	results in a non negative return value of ret_from_sys_call 
	which in turn leads to a never ending page fault. Therefore
	I will return (-1) regardless of the ret_from_sys_call result.
	Maybe we have to think about it, it may be wrong, but I don't
	know the linux semantics in this case at the moment

- dispatch_message_from_emulib now manipulates the user stack to prepare
  an iret stack frame. We have to verify the stack before manipulating it.
  At the moment it is done without checking the stack.

- Do we have to lock emu_local_lock and sig_handled before activating
  a new user process? Is it possible, that signals are delivered
  before activate_process jumps to the very first user instruction?	

- The emacs problem is now reproducable. When started the second once
  emacs touches a distinct address and raises a segmentation fault.

- There seems to be a bug within our signal handling after a segmentation 
  fault. The registers are looking different at moment when the
  segmentation fault occurs and when it is handled. Maybe there is a
  bug in the L4 kernels lthread_ex_regs, but I'm not shure at the moment.

- Hmm, I have tried to send a 3 dword message to resolve a pagefault.
  I thought that would raise a user level pagefault because of failing
  ipc.  But the ipc succeded without an error and the result on the
  receivers side said that 3 dwords were received. Strange ...

