On Mon, 14.04.14 14:16, Ryan Lortie (de...@desrt.ca) wrote: > Before we realised that this bug was a problem, however, having the bus > driver was clearly closer to "classic dbus-1".
Yupp, and we do revisit what we do from time to time and do change our opinions after consideration, which any engineer should do. > > If you want i can put together a "reference implementation" of the > > hashing logic. You'd just pass a list of tokens to add to the hash > > vocabulary, and we return you the match hash. You could then drop that > > into your sources, and you can update it when we do another revision of > > the protocol, and all that without breaking compat. > > I'd actually prefer if you put together a library that was the interface > to kdbus. If it's not possible to have the higher-level logic in the > kernel, then why not have it in userspace? If everyone is using the > same shared library then Well, I am not going to write a second library, you can be sure about that. I really don't understand you anymore I must say. It feels as if you want to play the abstraction game to somehow improve your karma with the freebsd guys, and I really don#t understand at all what the point of that is. YOu know, we can certainly change sd-bus to allow creation of sd_bus_message objects from binary gvariant blobs and fd arrays, but that's just a recipe for bad performance, and creates a huge headache when using the socket backend. It was actually my intention to make sure that the actual kdbus transport was high performance enough too be sueful for gnome apps to transfer bluk data. With such abstraction games you make such a goal incredibly hard. I really don't see why you even want to play this game. Lukas is doing the work on the kdbus port of glib, and he's willing to sheperd the thing into repo, and maintain it. Really, Ryan. Stop playing this stupid abstracted interface game. You are creating a crap platform like that. A big part of what kdbus is about is about minimizing copies for method call transactions. For this we leave memory management and layout of message objects to the sender and copy them together only at the last possible step. By wanting us to do this all for you you kinda force us to either create a complex callback-on-destroy scheme, or to copy early on. I am really strongly against either. > a) we don't have n copies of the bus interface copied everywhere Well, stop pretending that "n" is a large number. It's pretty much 2, not more. One in glib and maybe one in libdbus1, if we want that to speak kdbus directly. sd-bus won't carry one. > We run into trouble if we can have multiple versions of this library Why? > I'd also be open to the idea of defining a new bus type outright and > saying that it's not permitted to send messages to org.freedesktop.DBus > on this new bus type. Aside from my reservations about match rules, I > have no problem with turning GDBus API calls into ioctls (just as you do > in systemd). Sending messages to org.freedesktop.DBus on this new bus > type would fail (since the destination is unknown). This would give app > authors a chance to opt-in to move over to the new bus type and to deal > with compatibility issues as they do so. if this is what it takes... We have to create a new bus type anyway for the system bus, so that apps can acknowledge explicitly that they know how to do their own security. So maybe this is the easiest way out: introduce two new bus types in gdbus and by using those people can acknowledge that they: a) for the system bus are aware they need to do their own security b) for the user bus are aware they might not talk to a session anymore but a user bus c) that they cannot talk to the driver anymore, and need to use gdbus API calls instead And if people do not use the new bus types, we'd simply connect them to the old proxy. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
