Casey Schaufler wrote: > On 7/10/2015 7:57 AM, Alex Elsayed wrote: >> Stephen Smalley wrote: >> >>> On 07/10/2015 09:43 AM, David Herrmann wrote: >>>> Hi >>>> >>>> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <s...@tycho.nsa.gov> >>>> wrote: >>>>> On 07/09/2015 06:22 PM, David Herrmann wrote: >>>>>> To be clear, faking metadata has one use-case, and one use-case only: >>>>>> dbus1 compatibility >>>>>> >>>>>> In dbus1, clients connect to a unix-socket placed in the file-system >>>>>> hierarchy. To avoid breaking ABI for old clients, we support a >>>>>> unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is >>>>>> spawned once for each bus we proxy and simply remarshals messages >>>>>> from the client to kdbus and vice versa. >>>>> Is this truly necessary? Can't the distributions just update the >>>>> client >>>>> side libraries to use kdbus if enabled and be done with it? Doesn't >>>>> this proxy undo many of the benefits of using kdbus in the first >>>>> place? >>>> We need binary compatibility to dbus1. There're millions of >>>> applications and language bindings with dbus1 compiled in, which we >>>> cannot suddenly break. >>> So, are you saying that there are many applications that statically link >>> the dbus1 library implementation (thus the distributions can't just push >>> an updated shared library that switches from using the socket to using >>> kdbus), and that many of these applications are third party applications >>> not packaged by the distributions (thus the distributions cannot just do >>> a mass rebuild to update these applications too)? Otherwise, I would >>> think that the use of a socket would just be an implementation detail >>> and you would be free to change it without affecting dbus1 library ABI >>> compatibility. >> Honestly? Yes. To bring up two examples off the bat, IIRC both Haskell >> and Java have independent *implementations* of the dbus1 protocol, not >> reusing the reference library at all - Haskell isn't technically >> statically linked, but its ABI hashing stuff means it's the next best >> thing, and both it and Java are often managed outside the PM because for >> various reasons (in the case of Haskell, lots of tiny packages with lots >> of frequent releases make packagers cry until they find a way of >> automating it). > > There is absolutely no reason to expect that these two examples don't have > native kdbus implementations in the works already.
The Haskell one, at least, does not. I checked. > That's the risk you take when you eschew the "standard" libraries. > Further, the primary reason that developers deviate from the norm is (you guessed it!) performance. Or, you know, avoiding the hassle of building and/or linking to code in another language via FFI. That's my recall of the primary reason for the Haskell one - and I don't think it's any coincidence that the two pure reimplementations are in managed-but-compiled languages. > The proxy is going to kill (or at least be assumed to kill) that > advantage, putting even more pressure on these deviant applications to > provide native kdbus versions. ...sure, if performance was the object. But it went through the old D-Bus daemon either way, so I'm rather dubious of your assertion - whether due to being in userspace or just poor implementation, it's no speed daemon so to speak. > Backward compatibility shims/libraries/proxies only work when it's the > rare and unimportant case requiring it. If it's the common case, it won't > work. If it's the important case, it won't work. If kdbus is worth the > effort, make the effort. They also work if they require no configuration or effort from the legacy side, allowing those who need the (possibly rare *but also* important) benefits of the new system to benefit without causing harm to others. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/