id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	field_blocks	field_dependson	field_seealso
887	Decentralized DDF	Jiri Svoboda		"Currently DDF uses a dedicated central server {{{devman}}}, which provides the following functionality:

  1. Client-driver connection proxying
  2. Driver-driver connection proxying
  3. Driver task restarter
  4. Map compatibility strings (match IDs) to suitable driver
  5. Holds the device tree

In addition, the DDF provides an IPC dispatcher that allows one driver to provide multiple services (of possibly the same type) and one async session to provide multiple interfaces.

A new architecture is proposed, where no specialized {{{devman}}} is needed. The existing functionality is handled as follows:

  1. Client-driver connection proxying is not needed, clients connect directly to driver tasks (which they find via location service)
  2. Driver-driver connection proxying is not needed, drivers connect directly to other driver tasks (which they find e.g. via location service)
  3. Driver restarting is handled by a simple generic server restarter
  4. Each driver loads its own comatibility strings into a service property. Matching driver is found by looking up service properties in location service
  5. Device tree is distributed among driver tasks

The specialized DDF dispatcher is supplanted by the generic async mechanisms.

Dependencies:
  1. introduce a simple generic service restarter
  2. async ports/interface dispatcher must be improved to be a suitable replacement for DDF's dispatcher
  3. location service needs to implement service properties
"	enhancement	new	major		helenos/unspecified	mainline