Commit 2ea58ce8 authored by Blaise Thompson's avatar Blaise Thompson

buses

parent 5f59ede9
---
yep: 112
title: Buses
author: Blaise Thompson <blaise@untzag.com>
status: draft
tags: standard
post-history: 2020-11-24
---
# Abstract
Sometimes multiple daemons share a single physical interface (a single [bus](https://en.wikipedia.org/wiki/Bus_%28computing%29)).
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.
# Table of Contents
[TOC]
# Motivation
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](https://www.newport.com/p/SMC100CC).
These controllers can be [daisy-chained](https://en.wikipedia.org/wiki/Daisy_chain_(electrical_engineering)) 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](https://yeps.yaq.fyi/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.
This YEP defines..
# Specification
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.
## Configuration
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.
## Launching
`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
Discussion can be found on the [gitlab issue](https://gitlab.com/yaq/yeps/-/issues/26) for this YEP.
# Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment