31 ms·

Rethinking the D-Bus Message Bus

253 points by kragniz 9y ago

zokier 9y ago
Just noticed that this lives under bus1 github organization; does that imply that eventually it will be using bus1? Btw, whats happening at bus1, haven't heard about it lately?
- 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 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 ;)
- ploxiln 9y ago
  When kdbus was first proposed for merging, Linus basically said something like "dbus is way more inefficient than just kernel api limitations would require, fix that first before proposing a new kernel feature". So that seems to be what they're looking into now. ref: https://lkml.org/lkml/2015/6/23/657 https://lkml.org/lkml/2015/6/23/657
baybal2 9y ago
As I remember from more than a decade ago, the selling point of DBUS was that they were not trying to design a high performance message bus with sophisticated work mechanisms in spirit of Corba and Bonobo, but a small, flexible, and utilitarian one. Things like implicit message buffering were deliberate design decisions.
- vidarh 9y ago
  I wish they'd just build something simple, like AREXX. There's a reason AREXX ports were in almost every AmigaOS app: It was trivially simple to get started. The network effects were huge - pretty much any app was simple to automate. People to some extent built their apps as message pumps where input events (mouse, keyboard) triggered the same command hooks as AREXX messages, so every little piece of the app was scriptable. If you wanted a more advanced API than AREXX could reasonably accommodate, it was easy enough to layer the more complex bits next to it. The threshold for people to take full advantage of DBus is still too high. Maybe there's a need for something that complex for inter-application communication, but if so we'd also benefit from something simpler. Maybe it's just a documentation failure... I don't know.
- ajross 9y ago
  IMHO the problem with D-Bus was that it was never small and utilitarian. They decided (correctly) to ignore all the engineering effort involved in performance and scalability, and put all that overengineering into the API instead. D-Bus code is basically unreadable, as not only are the bus names heavily scoped (java-style) to avoid collisions, but also the interface and method names. A tiny python (or whatever) script to invoke a single method on a well-known object should be a one-liner but in practice lives over 6-7 lines just due to verbosity. D-Bus types are inexplicably low-level for a "utilitarian" IPC mechanism, leading to a bunch of type conversion to do simple things, and a ton of marshalling code in the core. Javascript has shown us how far you can get with just IEEE doubles and UTF-8 strings, yet D-Bus suffers with a type model that looks more like C.
  - fiddlerwoaroof 9y ago
    Yeah, I used to have a whole bunch of shell scripts to automate KDE 3 apps via dcop and then when dcop was dropped in favor of dbus, the complexity of the latter system discouraged me from porting the scripts. Whatever technical limitations dcop may have had, its command line was amazing: space separated words and a emphasis on discoverability made it a joy to use
    - simcop2387 9y ago
      qdbus is an almost adequate replacement for that. It's still more verbose and a bit more difficult to pass some arguments (this is all from memory) than dcop was, but it's servicable.
  - lima 9y ago
    pydbus nicely abstracts away much of that: https://github.com/LEW21/pydbus https://github.com/LEW21/pydbus
    - hp 9y ago
      right, nobody was ever intended to use the raw protocol details directly... those details were intended to support an API that looked like using in-process objects (well, perhaps in-process objects with methods declared as 'async').
onli 9y ago
That sounds reasonable. I'm very surprised. Disabling remote targets, ignoring SELinux, focusing on reliability. DBus is the one part of the modern linux desktop I would like to/have to install to get the applications I want running, even though I dislike it a lot (pulseaudio and systemd one can just not install). One example is the password remember function of steam. Having a more reasonable implementation could help with this a lot.
- tomegun 9y ago
  For the record: dbus-broker has full SELinux support.
  - onli 9y ago
    Well, I don't mind either way. https://github.com/bus1/dbus-broker/wiki#using-dbus-broker https://github.com/bus1/dbus-broker/wiki#using-dbus-broker says it has to be disabled.
    - tomegun 9y ago
      Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).
- pinpeliponni 9y ago
  Hmm. If it doesn't have SELinux policy that actually does something, it probably shouldn't run as a daemon. Let's see how I can remove it... :(
  - 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?
j_s 9y ago
I'm sure systemd would be happy to take over responsibility for this functionality. (Sorry, couldn't resist!)
- Rjevski 9y ago
  If systemd does it right (just like it did with making service management) then I see no issues with this.
  - TazeTSchnitzel 9y ago
    When has that ever happened?
    - Rjevski 9y ago
      Since systemd became mainstream? If only you've seen the time, money and sanity I saved when I switched to systemd instead of suffering with prehistoric initscripts.
      - atemerev 9y ago
        There were many other modern init replacements which did the job better than init scripts and better than systemd. I like my systems elegant, transparent and bloat-free. Systemd is none of that.
        acdha 9y ago
        … and yet, oddly, most of the distribution maintainers who reviewed them picked systemd. That doesn't mean it's perfect but it does suggest this conversation would be far more productive if you reviewed the historical discussions to see the reasoning behind those decisions.
        atemerev 9y ago
        The reasoning was hammering it down to everybody's throats by Redhat. It is easier to adapt to proposed solution (even inferior) where there are some guarantees of support and traction, than to reinvent everything and be left as sole maintainers. It doesn't relate in any way to the quality of the solution.
throw7 9y ago
are you still required to reboot the system if you upgrade "dbus-broker"?
- tomegun 9y ago
  Yes, for the time being we do not support reexecution.
revelation 9y ago
Ahh yes, we know this all too well, the Linux desktop trap: iterative work is lame, the old solution is so bad it's not even wrong, here is my idea for a rewrite, look it's even still compatible (for another few minutes).
- asveikau 9y ago
  I disagree with this characterization, because they explicitly state that compatibility with the original is a goal. When people have the more careless "re-write and throw-away" attitude, they often abandon the old API too. So this reads more of a strategic re-write, or re-do of implementation while keeping API, which I think is often a smart way to do it.
- jzl 9y ago
  aka the "CADT" model. :) https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html But, not saying that characterization applies here specifically. The article was quite well-reasoned in explaining the proposed changes, as far as I could tell. Disclaimer: I barely know anything about D-Bus.
chme 9y ago
So is the dbus-broker the latest project from the kdbus/bus1 guys. Since from the text dbus-broker does not use the bus1 kernel module, does that mean the bus1 project is dead?
- tomegun 9y ago
  bus1 is very much not dead. We intend to work on the next RFC soon.
  - oconnor663 9y ago
    If bus1 magically landed tomorrow, what would that mean for dbus-broker? Are the projects related at all, or mostly doing different things?
    - 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 broker) when possible.
  - chme 9y ago
    Great to hear! Keep up the good work Tom and friends!
atemerev 9y ago
Dbus is bloated hell. Whoever came with the idea "let's cram all communications from all sources into the single unified data stream, and let the clients fish what they need out of it" had the strange mapping of mental processes, to say the least. Most other forms of IPC are better (more scalable, more elegant, more comprehensible) — "everything is a file" is better, actor model is better, and I nearly think that even plain shared memory is better than a common bus. There is a reason there is no "shared bus" in Internet communications.
- pjc50 9y ago
  Well, there's multicast, but nobody uses that. Some things use link-local broadcast. Personally I think the Windows messaging system would actually be a pretty good model to follow, especially if you could give it an actual payload and not just two words. It would certainly solve the actual problems DBus was built to address - media change notifications and things like that.
  - fusiongyro 9y ago
    We actually rely on multicast here at the NRAO for monitor and control of the VLA. I admit it's the only place I've heard of it being used. ZeroMQ is getting used more for those kinds of purposes; the Greenbank Telescope uses it for one of their instrument backends and we are now using it for VLITE and REALfast. The new archive system I'm helping build uses AMQP.
    - jpm_sd 9y ago
      I have also seen ZeroMQ used for mobile robot control; it was considered for ROS 2.0 [1] before they settled on DDS [2] [1] http://design.ros2.org/articles/ros_with_zeromq.html http://design.ros2.org/articles/ros_with_zeromq.html [2] http://design.ros2.org/articles/ros_on_dds.html http://design.ros2.org/articles/ros_on_dds.html
    - jcurbo 9y ago
      This is fascinating (as an amateur astronomer), have you written anything else on the systems design of these types of instruments, or have any good pointers? I imagine for large instruments there is a massive amount of data involved and lots of stuff to control. I know it's bad enough with just my one telescope setup :)
arca_vorago 9y ago
"Linux Only" I like this approach more and more these days. For example, I run murmur(mumble) servers sometimes, and they deprecated d-bus support for ZeroC ICE (gplv2 or proprietary), but it seems almost as bloated if not more so. The reasoning was mostly around the portability bindings... Recently though, I have been refusing to support Windows and OSX as a concious decision. One thing I've found is that the constant want/need to target every platform adds an ever-increasing amount of complexity, which really seems to go against the unix philosophy. So I applaud others willing to buck the trend and narrow scope down. In the end, I think the main problem with the many eyes theory is that code has gotten so complex that there simply aren't enough eyes, and therefore I think the future of software is going to be in reduction of complexity. For example, loc isn't the best measure, but the Minix 3 kernel is at ~20kloc, while the Linux kernel is now at, what ~11mloc!? Not even redhat can audit that shit properly. (another reason we need a Hurd microkernel, but I digress)
- microcolonel 9y ago
  > the Minix 3 kernel is at ~20kloc, while the Linux kernel is now at, what ~11mloc!? Not even redhat can audit that shit properly. (another reason we need a Hurd microkernel, but I digress) Well, I don't think Hurd is going anywhere. They missed a crucial opportunity to move from Mach to L4 and they simply didn't have the manpower. What we might focus on is migrating facilities (drivers, core services like TCP, system services) from Linux, OpenBSD, Illumos, and Minix3(especially that daemon that can restart things even when the filesystem daemon goes kaput) to a well-designed L4 like seL4. At that point, at least we have some hope of taming the beast. The great opportunity here is that you don't need to care too much which license each driver or service is under, since they're all running in user space. You can have your (yuck) CDDL processes, where you keep your OpenZFS instance. You can have your GPLv2+ processes, where you keep your (maybe a bit dirty, but at least they exist!) Linux drivers. Also, the major difference in line counts is precisely because of the number of facilities offered by the Linux kernel (most of which you can disable, or would never be enabled in the first place!). Minix3 in its "equivalent" form (containing sufficient drivers for the machine running standard daemons) vs Linux with the same subset of drivers and services would be a much fairer comparison.
- 9y ago
Animats 9y ago
We rather consider a bus a set of distinct peers with no global state. If they've gone that far, they may as well implement QNX messaging, which is known to work well. QNX has an entire POSIX implementation based on QNX's messaging system, so it's known to work. Plus it does hard real time. The basic primitives work like a subroutine call. There's MsgSend (send and wait for reply), MsgReceive (wait for a request), and MsgReply (reply to a request). There's also MsgSendPulse (send a message, no reply, no wait) but it's seldom used. Messages are just arrays of bytes; the messaging system has no interest in content. Receivers can tell the process ID of the sender, so they can do security checks. All I/O is done through this mechanism; when you call "write()", the library does a MsgSend. Services can give their endpoint a pathname, so callers can find them. The call/reply approach makes the hard cases work right. If the receiver isn't there or has exited, the sender gets an error return. There's a timeout mechanism for sending; in QNX, anything that blocks can have a timeout. If a sender exits while waiting for a reply, that doesn't hurt the receiver. So the "cancellation" problem is solved. If you wan to do something else in a process while waiting for a reply, you can use more threads in the sender. On the receive side, you can have multiple threads taking requests via MsgReceive, handling the requests, and replying via MsgReply, so the system scales. CPU scheduling is integrated with messaging. On a MsgSend, CPU control is usually transferred from sender to receiver immediately, without a pass through the scheduler. The sending thread blocks and the receiving thread unblocks. With unidirectional messaging (Mach, etc.) and async systems, it's usually necessary to build some protocol on top of messaging to handle errors. It's easy to get stall situations. ("He didn't call back! He said he'd call back! He promised he'd call back!") There's also a scheduling problem - A sends to B but doesn't block, B unblocks, A waits on a pipe/queue for B and blocks, B sends to A and doesn't block, A unblocks. This usually results in several trips through the scheduler and bad scheduling behavior when there's heavy traffic. There's years (decades, even) of success behind QNX messaging, yet people keep re-inventing the wheel and coming up with inferior designs.
- 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 guiding principle.
digi_owl 9y ago
And i see the PR team is already out in force to sell this and defend what has already been sold. We should really just move to BSD already and let them sink this ship.
JdeBP 9y ago
One thing that I wonder about this is how it deals with the D-Bus Death Rattle. * https://jdebp.eu/FGA/dbus-death-rattle.html https://jdebp.eu/FGA/dbus-death-rattle.html
- 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 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.
  - JdeBP 9y ago
    Not every page on the WWW is a blog post, nor even every WWW site a web log to have blog posts on.
    - 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.

253 points by kragniz 9y ago

Just noticed that this lives under bus1 github organization; does that imply that eventually it will be using bus1? Btw, whats happening at bus1, haven't heard about it lately?

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 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 ;)
ploxiln 9y ago
When kdbus was first proposed for merging, Linus basically said something like "dbus is way more inefficient than just kernel api limitations would require, fix that first before proposing a new kernel feature". So that seems to be what they're looking into now. ref: https://lkml.org/lkml/2015/6/23/657 https://lkml.org/lkml/2015/6/23/657

baybal2 9y ago

As I remember from more than a decade ago, the selling point of DBUS was that they were not trying to design a high performance message bus with sophisticated work mechanisms in spirit of Corba and Bonobo, but a small, flexible, and utilitarian one. Things like implicit message buffering were deliberate design decisions.

vidarh 9y ago
I wish they'd just build something simple, like AREXX. There's a reason AREXX ports were in almost every AmigaOS app: It was trivially simple to get started. The network effects were huge - pretty much any app was simple to automate. People to some extent built their apps as message pumps where input events (mouse, keyboard) triggered the same command hooks as AREXX messages, so every little piece of the app was scriptable. If you wanted a more advanced API than AREXX could reasonably accommodate, it was easy enough to layer the more complex bits next to it. The threshold for people to take full advantage of DBus is still too high. Maybe there's a need for something that complex for inter-application communication, but if so we'd also benefit from something simpler. Maybe it's just a documentation failure... I don't know.
ajross 9y ago
IMHO the problem with D-Bus was that it was never small and utilitarian. They decided (correctly) to ignore all the engineering effort involved in performance and scalability, and put all that overengineering into the API instead. D-Bus code is basically unreadable, as not only are the bus names heavily scoped (java-style) to avoid collisions, but also the interface and method names. A tiny python (or whatever) script to invoke a single method on a well-known object should be a one-liner but in practice lives over 6-7 lines just due to verbosity. D-Bus types are inexplicably low-level for a "utilitarian" IPC mechanism, leading to a bunch of type conversion to do simple things, and a ton of marshalling code in the core. Javascript has shown us how far you can get with just IEEE doubles and UTF-8 strings, yet D-Bus suffers with a type model that looks more like C.
- fiddlerwoaroof 9y ago
  Yeah, I used to have a whole bunch of shell scripts to automate KDE 3 apps via dcop and then when dcop was dropped in favor of dbus, the complexity of the latter system discouraged me from porting the scripts. Whatever technical limitations dcop may have had, its command line was amazing: space separated words and a emphasis on discoverability made it a joy to use
  - simcop2387 9y ago
    qdbus is an almost adequate replacement for that. It's still more verbose and a bit more difficult to pass some arguments (this is all from memory) than dcop was, but it's servicable.
- lima 9y ago
  pydbus nicely abstracts away much of that: https://github.com/LEW21/pydbus https://github.com/LEW21/pydbus
  - hp 9y ago
    right, nobody was ever intended to use the raw protocol details directly... those details were intended to support an API that looked like using in-process objects (well, perhaps in-process objects with methods declared as 'async').

onli 9y ago

That sounds reasonable. I'm very surprised. Disabling remote targets, ignoring SELinux, focusing on reliability. DBus is the one part of the modern linux desktop I would like to/have to install to get the applications I want running, even though I dislike it a lot (pulseaudio and systemd one can just not install). One example is the password remember function of steam. Having a more reasonable implementation could help with this a lot.

tomegun 9y ago
For the record: dbus-broker has full SELinux support.
- onli 9y ago
  Well, I don't mind either way. https://github.com/bus1/dbus-broker/wiki#using-dbus-broker https://github.com/bus1/dbus-broker/wiki#using-dbus-broker says it has to be disabled.
  - tomegun 9y ago
    Indeed, thanks for the pointer! Removed that now (it was left-over from before we got SELinux support).
pinpeliponni 9y ago
Hmm. If it doesn't have SELinux policy that actually does something, it probably shouldn't run as a daemon. Let's see how I can remove it... :(
- 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?

j_s 9y ago

I'm sure systemd would be happy to take over responsibility for this functionality. (Sorry, couldn't resist!)

Rjevski 9y ago
If systemd does it right (just like it did with making service management) then I see no issues with this.
- TazeTSchnitzel 9y ago
  When has that ever happened?
  - Rjevski 9y ago
    Since systemd became mainstream? If only you've seen the time, money and sanity I saved when I switched to systemd instead of suffering with prehistoric initscripts.
    - atemerev 9y ago
      There were many other modern init replacements which did the job better than init scripts and better than systemd. I like my systems elegant, transparent and bloat-free. Systemd is none of that.
      - acdha 9y ago
        … and yet, oddly, most of the distribution maintainers who reviewed them picked systemd. That doesn't mean it's perfect but it does suggest this conversation would be far more productive if you reviewed the historical discussions to see the reasoning behind those decisions.
        atemerev 9y ago
        The reasoning was hammering it down to everybody's throats by Redhat. It is easier to adapt to proposed solution (even inferior) where there are some guarantees of support and traction, than to reinvent everything and be left as sole maintainers. It doesn't relate in any way to the quality of the solution.

throw7 9y ago

are you still required to reboot the system if you upgrade "dbus-broker"?

tomegun 9y ago
Yes, for the time being we do not support reexecution.

revelation 9y ago

Ahh yes, we know this all too well, the Linux desktop trap: iterative work is lame, the old solution is so bad it's not even wrong, here is my idea for a rewrite, look it's even still compatible (for another few minutes).

asveikau 9y ago
I disagree with this characterization, because they explicitly state that compatibility with the original is a goal. When people have the more careless "re-write and throw-away" attitude, they often abandon the old API too. So this reads more of a strategic re-write, or re-do of implementation while keeping API, which I think is often a smart way to do it.
jzl 9y ago
aka the "CADT" model. :) https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html But, not saying that characterization applies here specifically. The article was quite well-reasoned in explaining the proposed changes, as far as I could tell. Disclaimer: I barely know anything about D-Bus.

chme 9y ago

So is the dbus-broker the latest project from the kdbus/bus1 guys. Since from the text dbus-broker does not use the bus1 kernel module, does that mean the bus1 project is dead?

tomegun 9y ago
bus1 is very much not dead. We intend to work on the next RFC soon.
- oconnor663 9y ago
  If bus1 magically landed tomorrow, what would that mean for dbus-broker? Are the projects related at all, or mostly doing different things?
  - 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 broker) when possible.
- chme 9y ago
  Great to hear! Keep up the good work Tom and friends!

atemerev 9y ago

Dbus is bloated hell. Whoever came with the idea "let's cram all communications from all sources into the single unified data stream, and let the clients fish what they need out of it" had the strange mapping of mental processes, to say the least. Most other forms of IPC are better (more scalable, more elegant, more comprehensible) — "everything is a file" is better, actor model is better, and I nearly think that even plain shared memory is better than a common bus. There is a reason there is no "shared bus" in Internet communications.

pjc50 9y ago
Well, there's multicast, but nobody uses that. Some things use link-local broadcast. Personally I think the Windows messaging system would actually be a pretty good model to follow, especially if you could give it an actual payload and not just two words. It would certainly solve the actual problems DBus was built to address - media change notifications and things like that.
- fusiongyro 9y ago
  We actually rely on multicast here at the NRAO for monitor and control of the VLA. I admit it's the only place I've heard of it being used. ZeroMQ is getting used more for those kinds of purposes; the Greenbank Telescope uses it for one of their instrument backends and we are now using it for VLITE and REALfast. The new archive system I'm helping build uses AMQP.
  - jpm_sd 9y ago
    I have also seen ZeroMQ used for mobile robot control; it was considered for ROS 2.0 [1] before they settled on DDS [2] [1] http://design.ros2.org/articles/ros_with_zeromq.html http://design.ros2.org/articles/ros_with_zeromq.html [2] http://design.ros2.org/articles/ros_on_dds.html http://design.ros2.org/articles/ros_on_dds.html
  - jcurbo 9y ago
    This is fascinating (as an amateur astronomer), have you written anything else on the systems design of these types of instruments, or have any good pointers? I imagine for large instruments there is a massive amount of data involved and lots of stuff to control. I know it's bad enough with just my one telescope setup :)

arca_vorago 9y ago

"Linux Only" I like this approach more and more these days. For example, I run murmur(mumble) servers sometimes, and they deprecated d-bus support for ZeroC ICE (gplv2 or proprietary), but it seems almost as bloated if not more so. The reasoning was mostly around the portability bindings... Recently though, I have been refusing to support Windows and OSX as a concious decision. One thing I've found is that the constant want/need to target every platform adds an ever-increasing amount of complexity, which really seems to go against the unix philosophy. So I applaud others willing to buck the trend and narrow scope down. In the end, I think the main problem with the many eyes theory is that code has gotten so complex that there simply aren't enough eyes, and therefore I think the future of software is going to be in reduction of complexity. For example, loc isn't the best measure, but the Minix 3 kernel is at ~20kloc, while the Linux kernel is now at, what ~11mloc!? Not even redhat can audit that shit properly. (another reason we need a Hurd microkernel, but I digress)

microcolonel 9y ago
> the Minix 3 kernel is at ~20kloc, while the Linux kernel is now at, what ~11mloc!? Not even redhat can audit that shit properly. (another reason we need a Hurd microkernel, but I digress) Well, I don't think Hurd is going anywhere. They missed a crucial opportunity to move from Mach to L4 and they simply didn't have the manpower. What we might focus on is migrating facilities (drivers, core services like TCP, system services) from Linux, OpenBSD, Illumos, and Minix3(especially that daemon that can restart things even when the filesystem daemon goes kaput) to a well-designed L4 like seL4. At that point, at least we have some hope of taming the beast. The great opportunity here is that you don't need to care too much which license each driver or service is under, since they're all running in user space. You can have your (yuck) CDDL processes, where you keep your OpenZFS instance. You can have your GPLv2+ processes, where you keep your (maybe a bit dirty, but at least they exist!) Linux drivers. Also, the major difference in line counts is precisely because of the number of facilities offered by the Linux kernel (most of which you can disable, or would never be enabled in the first place!). Minix3 in its "equivalent" form (containing sufficient drivers for the machine running standard daemons) vs Linux with the same subset of drivers and services would be a much fairer comparison.
9y ago

Animats 9y ago

We rather consider a bus a set of distinct peers with no global state. If they've gone that far, they may as well implement QNX messaging, which is known to work well. QNX has an entire POSIX implementation based on QNX's messaging system, so it's known to work. Plus it does hard real time. The basic primitives work like a subroutine call. There's MsgSend (send and wait for reply), MsgReceive (wait for a request), and MsgReply (reply to a request). There's also MsgSendPulse (send a message, no reply, no wait) but it's seldom used. Messages are just arrays of bytes; the messaging system has no interest in content. Receivers can tell the process ID of the sender, so they can do security checks. All I/O is done through this mechanism; when you call "write()", the library does a MsgSend. Services can give their endpoint a pathname, so callers can find them. The call/reply approach makes the hard cases work right. If the receiver isn't there or has exited, the sender gets an error return. There's a timeout mechanism for sending; in QNX, anything that blocks can have a timeout. If a sender exits while waiting for a reply, that doesn't hurt the receiver. So the "cancellation" problem is solved. If you wan to do something else in a process while waiting for a reply, you can use more threads in the sender. On the receive side, you can have multiple threads taking requests via MsgReceive, handling the requests, and replying via MsgReply, so the system scales. CPU scheduling is integrated with messaging. On a MsgSend, CPU control is usually transferred from sender to receiver immediately, without a pass through the scheduler. The sending thread blocks and the receiving thread unblocks. With unidirectional messaging (Mach, etc.) and async systems, it's usually necessary to build some protocol on top of messaging to handle errors. It's easy to get stall situations. ("He didn't call back! He said he'd call back! He promised he'd call back!") There's also a scheduling problem - A sends to B but doesn't block, B unblocks, A waits on a pipe/queue for B and blocks, B sends to A and doesn't block, A unblocks. This usually results in several trips through the scheduler and bad scheduling behavior when there's heavy traffic. There's years (decades, even) of success behind QNX messaging, yet people keep re-inventing the wheel and coming up with inferior designs.

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

digi_owl 9y ago

And i see the PR team is already out in force to sell this and defend what has already been sold. We should really just move to BSD already and let them sink this ship.

JdeBP 9y ago

One thing that I wonder about this is how it deals with the D-Bus Death Rattle. * https://jdebp.eu/FGA/dbus-death-rattle.html https://jdebp.eu/FGA/dbus-death-rattle.html

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 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.
- JdeBP 9y ago
  Not every page on the WWW is a blog post, nor even every WWW site a web log to have blog posts on.
  - 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.