FUTURES - a (growing?) set of possible future additions to syscalltrack.

In order to facilitate creative thinking, one should sit down and start
throwing down ideas for what could be done with syscalltrack, and what
features could be added to it that build on what we've got, and takes
it even further.

add anything you wish here - these are only ideas, not words written in stone.
------------------------------------------------------------------------------

- syscall parameter rewriting:
  support rules (actions) that allow manipulating the parameters passed to
  system calls. useful for changing file paths, changing network connection
  addresses/ports, etc.

- allow performing filtering based on files - should be based on inodes,
  unless the file is removed and re-created - this will require tracking
  file creation in general, to find that a new file with the same full path
  was created.

- support redirection of a syscall to user mode. can be used to completely
  modify the way system calls are executed, without writing kernel-level
  code.

- write a utility that performs 'strace-like' behaviour - it injects a one
  rule for each syscall, whose condition is only its pid, and then execs
  the real program. need to figure out how to support follow-fork there.

- create a mechanism to forward syscall invocations to remote machines?
  would this ever be useful, assuming that signals are hard to forward? or
  are they?

- create a graphical configuration program, to make building rules
  easier.

- create a 'pattern observer' program, which get *all* system call
  invocation by a certiain user/program and learns patterns, and then
  notifies once that program/user does something out of the ordinary. 
