I'm creating a project called motherboard, a kernel-backed service bus for Linux, designed for fast communication between applications and system services.

The idea came from a frustration I have with Linux application development: the system has very powerful primitives, but it doesn't have an application platform as unified as Windows or Android. To build a complete app, we often need to deal with a mix of sockets, D-Bus, portals, specific daemons, X11/Wayland, PulseAudio/PipeWire, systemd or alternatives, etc.

motherboard tries to address this problem by creating a common layer where applications talk to stable OS global interfaces, not concrete processes.

For example, an app should not need to know which daemon implements notifications. It should call something like:

 NotificationDispatcher.send(...) 

and the system should route that to whoever currently implements that service.

Today that implementation may live in a monolithic process. Tomorrow it may be split into multiple daemons. The application does not change, because it depends on the interface, not the implementation.

It may look like overengineering if you think about an isolated app talking to one specific daemon. But the problem here is different: an operating system needs to expose global APIs to many applications that do not know each other, while maintaining shared state, permissions, notifications, and real-time changes and you need the OS to be easily backwards compatible.

If the user changes the theme or the network state changes (like wifi strength, status, IP, etc...), the shell needs to update, open apps need to react, services may need to recompute state, and future applications I have never seen before need a stable way to observe that without knowing which processes implement each of those services.

That is why motherboard is not just “another IPC”. It tries to turn system services into stable interfaces with function calls, reactive stores, and eventually signals. For a small app, Unix sockets are enough. For an OS platform, you need a common layer.

What already works

The project already has a Linux kernel module called motherboardm, which exposes /dev/services.

Communication uses commands serialized with postcard and sent through ioctl.

Currently, I have implemented:

• asynchronous RPC-style calls;
• per-connection inboxes;
• latch file descriptors compatible with poll/epoll;
• inline file descriptor passing;
• identity metadata provided by the kernel, such as PID, UID, GID, and a flag indicating whether the identity comes from the initial namespace;
• reactive stores.

Stores are one of my favorite parts of the design. Stores are very similar in spirit to

My goal now is to get feedback on the design:

• does it make sense to model services as namespaces for functions, stores, and signals?
• do reactive stores at the service bus level seem like a good primitive?
• what security or lifecycle problems do you think I should handle early?
• should this stay in the kernel, or would some parts make more sense in userspace?

GitHub: