> And so does kdbus. By default, strict ordering is enforced when messages > are received, but optionally, that action may be constrained to messages > of a minimal priority. This allows for use cases where timing critical > data is interleaved with control data on the same connection. That's > described in kdbus.message(7), and is also covered by test cases.
More to the point "and so do POSIX message queues". They are also a standard, a cross OS feature and relatively cleanly implemented in kernel, ditto some classes of socket behaviour are similar and SYS5 IPC (of which we shall not speak further I hope 8) ). I'm not saying that they solve the problem but they might avoid some of the complexities. Filtering is generalizable in Linux with a few lines of code, so rather than hardcoding dbus semantics EBPF can express pretty much any uni/multi/broadcast filtering policy rule for dbus or anything else. I agree entirely with Havoc that the ease of use wants to be preserved and semantics at the top of the dbus library shoudn't change. Dbus does have the problem of being too easy to use badly, but that's hard to fix technically 8) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
