Except they're not wrong. We have a potentially infinite set of signals and data we'd like to communicate to programs and a very limited set of signals to do it with. I mean apache uses sigwinch as an exit code!
We have a potentially infinite set of signals and data we'd like to communicate to programs
Ah, I think I've identified your problem.
Signals are for alerting programs to a specific (small) set of changes of external states. There's nothing "potentially infinite" there (frankly having 2 different SIGUSR's is generous).
For transmitting arbitrary messages, Linux provides message queues, which are very nearly sockets (and the ways they aren't sockets make using them for IPC easier). What's the limitation there?
It lacks multicast, sure, but then receivers can just make their own queues and have the broadcaster send to them if you want that.
You answered it yourself. It lacks efficient multicast.
What dbus really needs is an efficient kernel-level capability-aware multicast IPC mechanism, and a total rewrite of the user-space daemon to not be rubbish.
All the user-space daemon needs to do is provide a registration point for other processes to find and connect to each other via (existing) unicast or (new) multicast mechanisms.
My initial thoughts were that kdbus /was/ that IPC mechanism, but it sounds like that might not actually be true.
