Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/