My apologies, it read like a blog. Seeing the parent page I see that it is not. Either way, my comment stands.
This is an application issue, not a brokre/daemon issue. The broker will (as dbus-daemon(1)) does, deliver all signals that clients subscribe to. If they subscribe to things they don't care about, that is something that…
Please note that this is still an implementation of the D-Bus specification, but trying to adhere to the principle of distinct peers. As is explained, this is not entirely possible when implementing D-Bus, so it is…
At the moment dbus-broker does not have code to take advantage of bus1, but we intend to explore adding bus1 support to dbus-broker, so that peers (if their libraries support it), would seamlessly communicate…
Not sure what you mean here. dbus-broker(1) supports SELinux exactly to the same extent as dbus-daemon(1) does. Also; remove what?
> Just noticed that this lives under bus1 github organization; does that imply that eventually it will be using bus1? That is something we intend to explore. The idea would be to let bus1 be used under the hood by dbus…
bus1 is very much not dead. We intend to work on the next RFC soon.
Yes, for the time being we do not support reexecution.
Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).
For the record: dbus-broker has full SELinux support.
Thanks.
"[S]omewhat arbitrary" is a correct description. We take something that is fundamentally partially ordered (real-world events that may happen exactly at the same time), respect the partial order and extend it to a total…
Indeed that is how we break ties (not exactly the PID, but you get the idea). The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending…
> They are claiming there's no global synchronization and a global order. Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/t... In particular, what we did is described here:…
> What, bothers me is what the fuck is an iovec! https://www.gnu.org/software/libc/manual/html_node/Scatter_0...
What makes you think we are not? What use case would you like to be taken into account in bus1 that is not? Open to suggestions (that is the point of an RFC after all ;) ).
Adding support for priority inheritance would be a natural extension to bus1.
Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But…
I don't see how. We should handle side-channel communication just fine. Care to give an example?
I don't get what you are trying to achieve with this discussion. You didn't provide any serious alternative, you just say that the issues don't matter to you. Obviously, if you do not care about any of the features,…
How? We give a list of issues in the email.
One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that…
I would say it is to create the primitives needed for a multicast-capable (n-to-n) local IPC system. Obviously in such a way that it is safe, reliable, predictable, scalable, fast and lightweight.
There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though. There is no sealing in bus1. The payload of a…
The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.
My apologies, it read like a blog. Seeing the parent page I see that it is not. Either way, my comment stands.
This is an application issue, not a brokre/daemon issue. The broker will (as dbus-daemon(1)) does, deliver all signals that clients subscribe to. If they subscribe to things they don't care about, that is something that…
Please note that this is still an implementation of the D-Bus specification, but trying to adhere to the principle of distinct peers. As is explained, this is not entirely possible when implementing D-Bus, so it is…
At the moment dbus-broker does not have code to take advantage of bus1, but we intend to explore adding bus1 support to dbus-broker, so that peers (if their libraries support it), would seamlessly communicate…
Not sure what you mean here. dbus-broker(1) supports SELinux exactly to the same extent as dbus-daemon(1) does. Also; remove what?
> Just noticed that this lives under bus1 github organization; does that imply that eventually it will be using bus1? That is something we intend to explore. The idea would be to let bus1 be used under the hood by dbus…
bus1 is very much not dead. We intend to work on the next RFC soon.
Yes, for the time being we do not support reexecution.
Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).
For the record: dbus-broker has full SELinux support.
Thanks.
"[S]omewhat arbitrary" is a correct description. We take something that is fundamentally partially ordered (real-world events that may happen exactly at the same time), respect the partial order and extend it to a total…
Indeed that is how we break ties (not exactly the PID, but you get the idea). The reason this works is that the only time we can have a tie is if there can be no causality between the events. I.e., the two sending…
> They are claiming there's no global synchronization and a global order. Need to update your textbook ;) http://research.microsoft.com/en-us/um/people/lamport/pubs/t... In particular, what we did is described here:…
> What, bothers me is what the fuck is an iovec! https://www.gnu.org/software/libc/manual/html_node/Scatter_0...
What makes you think we are not? What use case would you like to be taken into account in bus1 that is not? Open to suggestions (that is the point of an RFC after all ;) ).
Adding support for priority inheritance would be a natural extension to bus1.
Right, we only enforce the _order_ of message delivery, not the _time_ of deliver. I.e., consider the sequence of messages received on each peer, these sequences each respect a global, total order on all messages. But…
I don't see how. We should handle side-channel communication just fine. Care to give an example?
I don't get what you are trying to achieve with this discussion. You didn't provide any serious alternative, you just say that the issues don't matter to you. Obviously, if you do not care about any of the features,…
How? We give a list of issues in the email.
One should think the goals are conflicting, but they are not. The secret is that the order is partial, as you say, but from userspace's point of view it is indistinguishable from a total order. The only messages that…
I would say it is to create the primitives needed for a multicast-capable (n-to-n) local IPC system. Obviously in such a way that it is safe, reliable, predictable, scalable, fast and lightweight.
There is not really a permission system in bus1 any more than fd passing is a permission system. What bus1 gives you is the primitives to build a permission system though. There is no sealing in bus1. The payload of a…
The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.