Announcement

Collapse
No announcement yet.

D-Bus Broker 22 Released With Option To Use Newer Kernel Features

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

  • D-Bus Broker 22 Released With Option To Use Newer Kernel Features

    Phoronix: D-Bus Broker 22 Released With Option To Use Newer Kernel Features

    With BUS1 not looking like it will come to fruition anytime soon as an in-kernel IPC mechanism and the kernel module for it not being touched since last March, the same developers continue pushing ahead with Dbus-Broker as the user-space implementation focused on D-Bus compatibility while being higher performing and more reliable than D-Bus itself...

    http://www.phoronix.com/scan.php?pag...er-22-Released

  • #2
    I installed dbus-broker months ago and completely forgot about it. Pretty stable, no issues.

    Comment


    • #3
      Typo:

      Originally posted by phoronix View Post
      This Dbus-broker bpdate also has fixes for Musl libc support.

      Comment


      • #4
        One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?

        Comment


        • #5
          Originally posted by ermo View Post
          One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?
          Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?

          Comment


          • #6
            Originally posted by halo9en View Post
            I installed dbus-broker months ago and completely forgot about it. Pretty stable, no issues.
            Me too, I did it even on several different systems. I expected at least some issues, but couldn't find any so far :-)

            Comment


            • #7
              Originally posted by ermo View Post
              One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?
              I think in-kernel BUS1 would be handy because it would make DBUS available super early in the boot process.

              Comment


              • #8
                Originally posted by ermo View Post
                One has to wonder if BUS1 is even needed if the most critical and speed-sensitive issues can be now instead be solved by a (set of) eBPF program(s)?
                eBPF is not without is fair share of issues.

                Originally posted by Britoid View Post
                I think in-kernel BUS1 would be handy because it would make DBUS available super early in the boot process.
                This is on the right track. Even a ebpf version could be started really early from the initramfs so this is not the full story.

                eBPF is not a free lunch you have to spend building eBPF every start up of dbus. eBPF makes sense for items that are configurable large section of BUS1 stuff would be static code with no configuration so would make more sense as a build once solution. So a mix of eBPF and static code would make sense for implementing dbus in kernel space. eBPF like for permission rules.

                Originally posted by jacob View Post
                Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?
                The answer is a horrible no. Kernel space or userspace is the kernel scheduler that deals with priority inversion issues. Dbus-broker does not attempt to be a pure userspace solution this is why is not as cross platform as dbus daemon.

                Current dbus-broker is not pure userspace it need particular syscalls that are in Linux kernel 4.17 or newer so the kernel scheduler knows what the heck is going on.

                Yes one of the arguments for kdbus was priority inversion and the Linux kernel developers were like no you don't need kernel space for that instead you should be using following syscalls to give the right information to kernel to deal with that for you.

                Comment


                • #9
                  Originally posted by jacob View Post

                  Wouldn't a purely userspace implementation, Dbus-Broker included, suffer from priority inversion problems?
                  You tell me?

                  Comment


                  • #10
                    Originally posted by oiaohm View Post
                    Yes one of the arguments for kdbus was priority inversion and the Linux kernel developers were like no you don't need kernel space for that instead you should be using following syscalls to give the right information to kernel to deal with that for you.
                    And also there are additional ways of avoiding priority inversion, for example asynchronous processing, that apply to userspace just as well. (Low priority threads blocking mixed priority mutexes is not a great thing in the first place.)

                    Comment

                    Working...
                    X