3 ms·

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

by deng 12y ago

semi-extrinsic 12y ago
So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?
- deng 12y ago
  I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.
- scrollaway 12y ago
  KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
  - zurn 12y ago
    You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
    - detaro 12y ago
      I think the idea is "why use dbus to coordinate creation, rights assignment, ... of local sockets when you can push the data over dbus"?
      - zurn 12y ago
        Yes, that's what I was talking about. Current dbus is is using local AF_UNIX sockets for transport -> the current transport is plenty fast enough to push encoded video over.
  - jschwartzi 12y ago
    If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?
    - 0xFFC 12y ago
      As far As I can remember in mailling list one of kernel developer mention "android IPC (Its name I think is binder) is completely broken" , He didn't mention any evidence for his claim.
    - the_why_of_y 12y ago
      Android's Binder was already merged into the Linux kernel (not just "staging", the real thing) since 3.19... half a year now. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=777783e0abae3cab7555bb182776f9ffaa35631a https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... But not many people are aware of that; since neither systemd nor Lennart Poettering have anything to do with it, the usual armchair architects did not paste their, uhm, well considered opinions about how much it sucks and is the end of the UNIX philosophy all over the comment threads when it happened.
- mateuszf 12y ago
  PulseAudio
audidude 12y ago
I think wayland was one possibility.
kryptiskt 12y ago
I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?
- mburns 12y ago
  because they want the square hole for a reason, the square hole being a unified in-kernel IPC system. Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/ https://lwn.net/Articles/551969/
  - mcguire 12y ago
    "because they want the square hole for a reason, the square hole being a unified in-kernel IPC system." Another one?
    - mburns 12y ago
      No, a first one. The others aren't unified, they are niche solutions. Those specific shortcomings are covered in those KDBus talks. If the existing solutions were sufficient, why would the 'new' way ever get merged into mainline?
- justincormack 12y ago
  Well actually thats what kdbus would do anyway, all the large transfers will happen over memfd buffers...
hobarrera 12y ago
I'd much prefer a an IPC that lets me pass a socket and use that socket on both ends, instead of this. I really still don't see a good-enough scenario for this.
comex 12y ago
I'm not terribly convinced by this point, since it's relatively easily solved by the "transparent direct connection" idea that's been suggested in LKML. That is, rather than making the application set up its own Unix socket connection for the media, the DBus library would have a simple call to switch to a direct socket connection as a transport for a given DBus connection. This wouldn't work for multicast, but who needs to multicast raw media data to whatever local process feels like receiving it?

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

by deng 12y ago

IIRC the use case is to stream media over DBus, which currently no one is doing because it is too slow.

So: if DBus was suddenly fast enough to stream media over, what applications would be using this feature, for what sets of streaming endpoints?

deng 12y ago
I don't know. I'm not advocating kdbus for multimedia, I'm just repeating what I've heard. I think one of the driving forces behind kdbus is Samsung who are interested in kdbus for Tizen.
scrollaway 12y ago
KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
- zurn 12y ago
  You don't fling uncompressed video between apps like that, it goes straight to the hardware-accelerated h.264 (or whatever) encoder and then a low bandwidth stream comes out. Local AF_UNIX sockets (aka userspace dbus) provide ample bandwidth for that use case.
  - detaro 12y ago
    I think the idea is "why use dbus to coordinate creation, rights assignment, ... of local sockets when you can push the data over dbus"?
    - zurn 12y ago
      Yes, that's what I was talking about. Current dbus is is using local AF_UNIX sockets for transport -> the current transport is plenty fast enough to push encoded video over.
- jschwartzi 12y ago
  If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?
  - 0xFFC 12y ago
    As far As I can remember in mailling list one of kernel developer mention "android IPC (Its name I think is binder) is completely broken" , He didn't mention any evidence for his claim.
  - the_why_of_y 12y ago
    Android's Binder was already merged into the Linux kernel (not just "staging", the real thing) since 3.19... half a year now. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=777783e0abae3cab7555bb182776f9ffaa35631a https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... But not many people are aware of that; since neither systemd nor Lennart Poettering have anything to do with it, the usual armchair architects did not paste their, uhm, well considered opinions about how much it sucks and is the end of the UNIX philosophy all over the comment threads when it happened.
mateuszf 12y ago
PulseAudio

audidude 12y ago

I think wayland was one possibility.

kryptiskt 12y ago

I don't get the use case, why can't the programs use DBus to negotiate the streaming over some low-overhead transport? Why are people so insistent on ramming a square peg into a round hole?

mburns 12y ago
because they want the square hole for a reason, the square hole being a unified in-kernel IPC system. Greg KH has given a few talks/blogs about the design goals of kdbus. https://lwn.net/Articles/551969/ https://lwn.net/Articles/551969/
- mcguire 12y ago
  "because they want the square hole for a reason, the square hole being a unified in-kernel IPC system." Another one?
  - mburns 12y ago
    No, a first one. The others aren't unified, they are niche solutions. Those specific shortcomings are covered in those KDBus talks. If the existing solutions were sufficient, why would the 'new' way ever get merged into mainline?
justincormack 12y ago
Well actually thats what kdbus would do anyway, all the large transfers will happen over memfd buffers...

hobarrera 12y ago

I'd much prefer a an IPC that lets me pass a socket and use that socket on both ends, instead of this. I really still don't see a good-enough scenario for this.

comex 12y ago

I'm not terribly convinced by this point, since it's relatively easily solved by the "transparent direct connection" idea that's been suggested in LKML. That is, rather than making the application set up its own Unix socket connection for the media, the DBus library would have a simple call to switch to a direct socket connection as a transport for a given DBus connection. This wouldn't work for multicast, but who needs to multicast raw media data to whatever local process feels like receiving it?