Announcement

Collapse
No announcement yet.

Dbus-Broker 24 Brings Improved Log Messages

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dbus-Broker 24 Brings Improved Log Messages

    Phoronix: Dbus-Broker 24 Brings Improved Log Messages

    Dbus-Broker as the high performance, D-Bus compatible implementation with BUS1 not panning out yet for high-performance, in-kernel IPC has seen a new release...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Can someone really comment on what’s the state of bus1 project?

    Comment


    • #3
      Originally posted by intelfx View Post
      Can someone really comment on what’s the state of bus1 project?
      Perhaps more to the point, is bus1 superseded by dbus-broker, at least in terms of performance?

      Comment


      • #4
        BUS1 should be dropped... ...it's not going anywhere.

        Unless they maybe plan to do in-kernel inter-module communication?

        Comment


        • #5
          Originally posted by tildearrow View Post
          BUS1 should be dropped... ...it's not going anywhere.
          And you base this claim on what exactly?

          Comment


          • #6
            Linux userland (including systemd) would look differently if kdbus be included. They needed it not because of the speed, but to have it in the early boot. They ended up with dbus included in the systemd in the form of varlink. You thing guys what, bus1 would suddenly give you +100 fps in quake or make Gnome smoother? Even if kdbus was faster, you wouldn't see it in your home, but maybe super-specific cloud deployments. And the author is here- he said many times- you can ask him. I would rather ask after RH acquisition by IBM for serious money, how long will they do even care about being dependent on a out-of-company single person. I mean, they can now even say "systemd is now dependent on XYZ kernel module and you can pull it from our source tree" (as it's not mainlined)

            edit: Oh, one thing. I had a hope that maybe after eventually kdbus be implemented, systemd-consoled project would be bringed up.
            Last edited by ptrwis; 05 September 2020, 07:01 AM.

            Comment


            • #7
              Originally posted by intelfx View Post

              And you base this claim on what exactly?
              - Basically zero BUS1 users.
              - Having userspace IPC in the kernel is risky and dated.
              - dbus-broker ended up being the way to go, and the devs realized this the moment they conceived it, by totally stopping work on BUS1.

              Comment


              • #8
                Originally posted by tildearrow View Post

                - Having userspace IPC in the kernel is risky and dated.
                And where else would you suggest handling IPC with zero copy and some sort of access model?

                Originally posted by tildearrow View Post
                - dbus-broker ended up being the way to go, and the devs realized this the moment they conceived it, by totally stopping work on BUS1.
                Right, but AFAIK its just a faster implementation of dbus, while bus1 is a simpler IPC mechanisms with those properties.

                Originally posted by tildearrow View Post

                - Basically zero BUS1 users.
                If I understood it correctly, dbus-broker can be or will be usable on top of bus1. I don't know if that is the current goal, or if there just isn't enough manpower available for that.

                Comment


                • #9
                  Originally posted by PyroDevil View Post

                  And where else would you suggest handling IPC with zero copy and some sort of access model?
                  Shared memory. /dev/shm

                  Originally posted by PyroDevil View Post
                  Right, but AFAIK its just a faster implementation of dbus,
                  Which would work as a drop-in replacement for the standard D-Bus daemon, and applications would benefit from the performance improvements without any changes.


                  Originally posted by PyroDevil View Post
                  If I understood it correctly, dbus-broker can be or will be usable on top of bus1. I don't know if that is the current goal, or if there just isn't enough manpower available for that.
                  It is probably that.

                  Comment

                  Working...
                  X