Authors:Blaise Thompson


Sometimes multiple daemons share a single physical interface (a single bus). This shared interface may not be safe for use by multiple applications. Therefore it is sometimes necessary to force a collection of daemons to run together in a single process so flow control can be handled correctly by yaq. This YEP defines such a system.

PLEASE NOTE! While this YEP might be a good idea, yaq developers have decided to leave it as a draft for the time being. We have not, to our knowledge, encountered a concrete example where this bus system is necessary. We assume that such hardware will come to us at some point, and we will implement and finalize this YEP at that time.

Table of Contents


As a design guideline, yaq encourages the development of ultra-portable, single purpose daemons that interface with single components. For complex hardware, this often means that multiple daemons are written---each to control a particular component. This guideline makes individual yaq interfaces simpler and more trait-compliant, easing client development. However, this also introduces a techinical challenge: how to run multiple daemons using the same physical bus without collisions?

As a concrete example, consider Newport's SMC100CC motor controller. These controllers can be daisy-chained together to create a network of motors that are controlled via a single RS232 bus. This RS232 bus has no automatic flow control. In fact, Windows only allows one application to occupy a given COM port. In yaq the natural approach would be to have one daemon per motor. Different kinds of motors can be used within the same network, so a heterogeneous collection of daemons must somehow run within one process.

YEP-104 defines standard entry points for running yaq daemons. In this standard, all daemons of a given kind share a single entry point and are therefore launched together. As an implementation detail, daemons of the same kind CAN be run within one process, although this is not guaranteed.


In yaq, buses are special named entry points starting with yaqd-bus. Individual daemons can register to be run by a specific bus manager in configuration. There can be multiple bus kinds.

The bus system is completely optional. Daemons are not required to participate in buses.


Daemons should define a key yaqd-bus-<bus-kind> mapping to a string of an arbitrary name. These configuration options MUST appear in the protocol with default none. All daemons mapping the same bus-kind to the same bus-name will run together in a single process.


yaqd-bus-<bus-kind> <name>. This will launch all of the daemons with matching configuration. The bus entry point scans the configuration directory recursively looking for such daemons. An alternative configuration directory can be provided with a flag. If no daemons are found the bus should exit with an error.

Rejected Ideas

Abstracting away bus interfaces as RPC layers.


Discussion can be found on the gitlab issue for this YEP.


This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.

built 2021-01-15 15:42:48                                      CC0: no copyright