tomegun

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 should be fixed in the clients. During the kdbus times, quite some time was spent on fixing clients to avoid too broad subscriptions exactly to fix the issue described in that blog post.

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 guiding principle.

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 broker) when possible.

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 libraries to do peer-to-peer communication where possible (circumventing the broker) but still stay compatible to the D-Bus semantics.

> Btw, whats happening at bus1, haven't heard about it lately?

We spent half a year working on dbus-broker ;)

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 order. The extension is arbitrary, but I fail to see the problem with that, or how it contradict anything we wrote?

Could you explain what bounds you are interested in and in what way you think anything is exaggerated? I would like to update the docs if necessary.

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: the two ioctl calls overlap in time, so there would be no way for one to have caused the other.

What problem do you see with this?

> 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: https://github.com/bus1/documentation/wiki/Message-ordering

If anything is unclear or misleading, please let me know and I'll try to clarify.

> 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 there are no timestamps on them, and no way to compare sequences from separate peers.

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, then you should not be using bus1. But that does not mean that others don't care, so why are you objecting so strongly to us providing a solution to these problems?

Firstly, if you don't want a bus IPC with multicast messaging, then use something else. But if you DO want that, then you cannot ignore message ordering, that is the whole point (otherwise you could just use repeated unicast instead).

If you want message ordering you cannot split things into several daemons, or you break the order (unless you add some more communication on top). Same with p2p (side-channel) communication for FDs.

The broker is basically doing work on behalf of the sender, but without proper time-slice accounting it is not accounted accordingly. Obviously in many cases that does not matter, but you cannot simply ignore the problem if you want a general, lasting solution.

It is true that performance is not the main feature, but that is not to say that it does not matter at all (to anyone, ever), so you cannot simply brush it aside, proposing a solution that would have (almost by definition) hundreds of percent worse performance (as you are just doing more round-trips, even ignoring the context switching). To say that IPC latency is "not the bottle neck" only makes sense if you have a specific use-case in mind. With sufficiently low latency, we open up the possibility of using IPC for things that could only be done in-process today. This is not the MAIN purpose, but ignoring it is short-sighted.

I just got an email today from people asking about the LSM hooks, so there certainly is interest, and this (like the message order) is not something you can bolt on top.

I have not seen Linus comment on this, please give a link if you have. Whatever reservations he had about kdbus should not apply to bus1.

Look, there are plenty of things that could be improved on bus1, and I'm sure some careful review will find things we could and should do differently, but please at least spend more than five seconds looking into what we did and thinking about the problem. We want a multicast IPC system, but we want one done properly. You cannot simply say that doing one that is several times slower, doesn't do proper resource accounting, gets the message order wrong and cannot integrate with LSM is "good enough for me" and expect that to be the end of it.

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 are not well ordered are messages that can never interact, so it is not possible to observe the lack of order from userspace. I wrote up how it works here: https://github.com/bus1/bus1/wiki/Message-ordering

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 bus1 message is exactly the same as the payload of a UDS message: unstructured binary data. bus1 is (like UDS) just a transport, it would be up to the consumer to add structured payload if they wish.

kdbus is higher level than bus1, don't confuse the two. kdbus is still not at the application level though, there would have to be a userspace component inbetween.

High-level abstractions for applications don't belong in the kernel, I agree. But that is a strawman, bus1 is not doing that at all.

The overhead due to the message ordering is constant, irrespective of the number of cores/peers. See the link posted above for an explanation.

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.

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 currently supported). If the second lowest bit (BUS1_NODE_FLAG_ALLOCATE) is set a new handle should be allocated by the kernel, otherwise the handle ID must refer to an existing handle.

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.

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, who submitted it upstream, etc.

bus1 needs init's cooperation in the same way UDS does. It is simply a nonsensical statement, bus1 is simply a transport, what apps do on top is a different topic.

When I said that bus1 should be reasonably portable, I meant exactly that: the code of bus1 itself should be easy to port to other OSs. Whether apps that use bus1 are easy to port to systems without bus1 depends on how what they do and what is available on the other systems in question...

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).