tomegun

6 ms·

1.
by tomegun 9y ago
My apologies, it read like a blog. Seeing the parent page I see that it is not. Either way, my comment stands.
2.
by tomegun 9y ago
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 should be
3.
by tomegun 9y ago
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 nothing more than a guidi
4.
by tomegun 9y ago
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 peer-to-peer (circumventing the
5.
by tomegun 9y ago
Not sure what you mean here. dbus-broker(1) supports SELinux exactly to the same extent as dbus-daemon(1) does. Also; remove what?
6.
by tomegun 9y ago
> 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 libraries to do pe
7.
by tomegun 9y ago
bus1 is very much not dead. We intend to work on the next RFC soon.
8.
by tomegun 9y ago
Yes, for the time being we do not support reexecution.
9.
by tomegun 9y ago
Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).
10.
by tomegun 9y ago
For the record: dbus-broker has full SELinux support.
11.
by tomegun 10y ago
Thanks.
12.
by tomegun 10y ago
"[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 order. The
13.
by tomegun 10y ago
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 events happen concurrently
14.
by tomegun 10y ago
> 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
15.
by tomegun 10y ago
> What, bothers me is what the fuck is an iovec! https://www.gnu.org/software/libc/manual/html_node/Scatter_0...
16.
by tomegun 10y ago
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 ;) ).
17.
by tomegun 10y ago
Adding support for priority inheritance would be a natural extension to bus1.
18.
by tomegun 10y ago
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 there are no timestamp
19.
by tomegun 10y ago
I don't see how. We should handle side-channel communication just fine. Care to give an example?
20.
by tomegun 10y ago
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, then you
21.
by tomegun 10y ago
How? We give a list of issues in the email.
22.
by tomegun 10y ago
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 are not well order
23.
by tomegun 10y ago
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.
24.
by tomegun 10y ago
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 bus1 message is exactl
25.
by tomegun 10y ago
The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.
26.
by tomegun 10y ago
Did you read the ksummit email? There were eight reasons given, performance was one of them (the third one). Not the only one. Not the main one.
27.
by tomegun 10y ago
Hehe, that was the only part of this article I didn't particularly love. This is how it works: A handle ID is a 64bit integer. If lowest bit (BUS1_NODE_FLAG_MANAGED) is set it is a handle ID allocated by the kernel (the only mode curre
28.
by tomegun 10y ago
memory sealing can be used by anything that can do fd passing, which bus1 does (as does UDS). That code is already upstream and was not really tied to kdbus.
29.
by tomegun 10y ago
Please look at the code. bus1 is no more high-level than UDS. You 'gather' a lot about how this works, please look at the code/docs before writing things. 'kdbus' was Lennart's baby? Look at who wrote the code,
30.
by tomegun 10y ago
See the ksummit announcement elsewhere in this thread. The list of issues is given there. We could get 95% of the way in userspace, but not all the way (the issues are by no means obvious or trivial, so take a look at the announcement).

More ›