Recent Features
| |||||||||||||
this isn't moving D-Bus into the kernelthis isn't moving D-Bus into the kernelPosted Feb 9, 2013 3:10 UTC (Sat) by dlang (✭ supporter ✭, #313)Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
This is implementing a IPC mechanism that DBUS can be layered over. This lets them avoid locking in D-Bus specific warts.
Think of it as D-Bus made with 20-20 hindsight :-)
(Log in to post comments)
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 7:35 UTC (Sat) by wahern (subscriber, #37304) [Link]
Reliable multicast is fundamentally something that doesn't belong in the kernel. The kernel handles discrete operations, and leaves user land to manage long-term state with unbounded time and space requirements.
I don't get the drive to move stuff like this into the kernel. It's a poor fit.
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 7:46 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> I don't get the drive to move stuff like this into the kernel. It's a poor fit.
I think the drive is performance (not just throughput, but reduced overhead at providing the service)
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 8:23 UTC (Sat) by wblew (subscriber, #39088) [Link]
There are differences between remote (inter-host) reliable multicast and local (within single host) reliable multicast. For one, the packet loss behaviour is quite different.
Perhaps such differences makes local reliable multicast less of an issue?
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 8:42 UTC (Sat) by Wol (guest, #4433) [Link]
Does that mean d-bus will work properly over a network?
I understood that at the moment d-bus doesn't work well if you try to run the program on one system and the display on another. It'd be nice if remoting did work well, as I use an old system as an x-term and at present it's painful ...
Cheers,
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 16:10 UTC (Sat) by hitmark (guest, #34609) [Link]
Welcome to the world that have not been thinking of network as more than HTML/FTP/SSH servers and clients in over a decade. The only places to come close to "network as a computer" is in old SUN ads and clusters (and perhaps Plan9, but mention that without context and most will think movie not OS).
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 18:37 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
No. DBUS is a local IPC, it's explicitly NOT targeted for networked IPC. For example, DBUS allows to send file descriptors and credentials with the messages.
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 18:55 UTC (Sat) by Wol (guest, #4433) [Link]
YUCK!!!
So it most definitely isn't unixy!!!
Hopefully X over Wayland, or Wayland over X, will fix it, but it would be nice if it let you run programs properly over the network.
Cheers,
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 19:16 UTC (Sat) by drag (subscriber, #31333) [Link]
Well there are lots of IPC that doesn't work over networks. Like 'Shared Memory Segments', 'Semaphore Arrays', and 'Message Queues'. I don't know if you consider those 'unixy' or not, but they certainly have been around in Unix for a long time.
this isn't moving D-Bus into the kernel Posted Feb 10, 2013 7:14 UTC (Sun) by pbonzini (subscriber, #60935) [Link]
And OMG, pthread condvars are not file descriptors!
this isn't moving D-Bus into the kernel Posted Feb 10, 2013 0:03 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Next you'll say that UNIX sockets are not UNIX enough for you...
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 19:34 UTC (Sat) by guelfey (guest, #89259) [Link]
The spec allows a tcp transport (http://dbus.freedesktop.org/doc/dbus-specification.html#t...), even if I assume nobody uses it because it's not secure at all.
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 19:39 UTC (Sat) by drag (subscriber, #31333) [Link]
things like this makes me wish that ipsec actually worked well. Transport mode for the win.
this isn't moving D-Bus into the kernel Posted Feb 9, 2013 21:40 UTC (Sat) by lkundrak (subscriber, #43452) [Link]
It might not work well, yet it sort of works somehow.
https://bugzilla.redhat.com/attachment.cgi?id=359864
this isn't moving D-Bus into the kernel Posted Feb 11, 2013 11:31 UTC (Mon) by k3ninho (subscriber, #50375) [Link]
>Reliable multicast is fundamentally something that doesn't belong in the kernel. The kernel handles discrete operations, and leaves user land to manage long-term state with unbounded time and space requirements.
Embarrassingly-parallel algorithms get a big boost out of shared data structures when memory access can be mitigated by L3-tier caches. The wider the compute capabilities of the processor - and the future is wide, if not clockspeed-fast - the better.
K3n.
this isn't moving D-Bus into the kernel Posted Feb 12, 2013 15:24 UTC (Tue) by FranTaylor (guest, #80190) [Link]
How exactly does on synchronize multicast data access to multiple threads WITHOUT involving the kernel?
And are you really so sure that the kernel currently provides ALL of the functionality necessary to perform this functionality, optimally?
What you are saying is like, "if we had a primitive read() command that only takes one character, that is sufficient, just call it over and over. It is not the place of the kernel for optimizations like being able to write multiple characters at once"
|
|||||||||||||