DirectFB 1.6: IPC

From DirectFB

Revision as of 10:36, 5 July 2011 by Dok (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

DirectFB - New Core Architecture

Motivation

  • Shared memory and global locks are no longer acceptable for multi process DirectFB, except for pixel data or other resources like vertices etc.
  • Two different mechanisms for IPC and RPC are currently in place (Fusion and Voodoo), create one common framework for distributed components

Status

There's a new secure-fusion branch, already featuring a code generator to ease the later transition from Secure Fusion to new IPC, Voodoo or whatever it will be in the end, probably the best of both. It is called Flux and is very small and efficient, somewhat like IDL. Here's an example.

Requirements

  • Keep possibility to build for single process usage, plain direct calls, possibly single threaded
  • Different applications shall have different permissions, e.g. to call certain functions or use certain parameters (trusted and untrusted applications)
  • Network transparency is required for distributed components like dynamically registered input devices fed from another host
  • Shared memory should be possible even between two hosts if they run on the same board (two CPUs with a kernel each, but sharing physical memory)
  • Everything possible in single process DirectFB must be possible in multi process as well
  • System backends should not need any special code to be used by multi process DirectFB, modules working in single process DirectFB shall always work in multi process as well
  • System backends should still be able to provide direct rendering or other optimizations, e.g. when running on the same kernel or hardware
  • It should be possible to show a window on multiple hosts, transparent to the application, e.g. for multi head view on multiple TV sets

Steps

The following are initial steps to be taken:

  • Start with read-only mapping of shared memory pools from slave processes, only master can write to non-pixel shared memory pools, using more IPC calls
    • Implement using file system permissions (each pool is a file anyhow)
    • Two users (master and slave) in one group
      • Master user owns pools and has write access
      • Slave user has only read permission via group policy
  • Eliminate any pointers sent from slaves to master when calling an IPC function (for references IDs only)
    • New FusionCall2 already supports to append variable length payload instead of using just one pointer and one integer per call
  • Object ownership
    • Methods of objects may only be callable from owner


The following are intrusive changes to the architecture, taking place in the unstable 1.6 branch.

  • Throw away Fusion
  • Extend VoodooPlay to manage the processes and the services they provide (peers)
    • each process has a core, even if empty
    • components like screens, layers, input devices could be created in a platform (or master) process
    • local surface pools in each peer
    • remote (proxy) pools representing pools from other peers
    • partial locking of buffers and synchronization on demand
    • peers may also provide output components and show a window or the composited stack of the other peer (VNC like)
  • Create IDL files for the new DirectFB core API
  • Generate code for single process and multi process
    • Single process uses direct calls whenever possible
    • Multi process is based on a refactored Voodoo
  • Manage shared memory pools with fine grained permissions


to be continued...

Personal tools