On 04/14/2014 08:16 PM, Ryan Lortie wrote:
hi,
Hi,
On Mon, Apr 14, 2014, at 12:08, Lennart Poettering wrote:
Au contraire. I am pretty sure that with handling the driver client side
makes things much simpler and closer to classic dbus1.
I agree. No races, after all, in practice.
Before we realised that this bug was a problem, however, having the bus
driver was clearly closer to "classic dbus-1".
Yes, I agree with Ryan - having driverd is closer "classic dbus-1" than
emulating all ioctl()s in GLib. Emulating messages without sending it
can be confusing for app developers - for example work with
dbus-monitor can be at least "difficult" in that case.
Ryan wrote that he and David had some ideas how systemd-driverd might
be fixed, so maybe it's worth the effort? I think that removing systemd
driverd (org.freedesktop.DBus instance) will be yet another argument
for kdbus opponents that kdbus - as a replacement for old dbus solution
- implements completely different semantics. Now we have working whole
OS (without politics) on kdbus, systemd (driverd and bus-proxy), glib
with native support, so maybe we should focus our effort to fix current
bugs (like race in dirverd).
With the new scheme we can simply drop the on-behalf-of thing,
everything becomes much simpler, we need no further synchronization, the
right synchronization happens automatically, because we schedule things
exactly as we did on dbus1.
I agree that being able to drop this is also nice.
No. We are not going to marshal/demarshal things in the kernel. This is
a total no-no.
...and I understand your constraints here.
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
a) we don't have n copies of the bus interface copied everywhere
and
b) managing changes is made a lot easier: we change in one place
We run into trouble if we can have multiple versions of this library
installed, of course (ala jhbuild), but at least it shrinks the problem
a bit.
Lennart, I'm curious what do you think about it?
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.
I am really strongly not interested in having several copies what
essentially amounts to implementations of the org.freedesktop.DBus API
scattered all over. This is really not a good approach and it _will_
bite us if we ever want to change things here. It's also ugly.
You are highly unfair. It's really now a question of marshalling to
different things conditionally:
foreach message to send:
a) if destination == org.freedesktop.DBus → marshal to gvariant,
send with sendmsg()
b) if destination != org.freedesktop.DBus → marshal to some
struct, send with ioctl()
foreach message received via recvmsg():
a) if sender == kernel → marshal from struct
b) if sender != kernel → marshal from gvariant
This is a pretty big stretch. This is not a simple question of
different marshalling formats. Taking a method call with a particular
name (effectively matching on magic strings) and converting that into an
ioctl() and then generating a new message (the reply) and sending it
back to my user as if it is an incoming message is not just a different
kind of marshalling. This is pretending to be something that we're not
in order to fool the application into not noticing the difference, and
it's definitely a hack.
That's never goingto happen. We are not going to demarshall things in
the kernel. I know that Canonical wants that for its app sandboxes, but
it's just against the whole excercise. This is not going to fly. We do
direct userspace-to-userspace copies, and that allows us to do
single-copy IPC. We are not going to fuck this all up to just get back
to the old 10-copy design of dbus1.
I'm not sure what Canonical wants to do with app sandboxes or what it
has to do with kdbus. I'm talking strictly as someone who doesn't want
to introduce a chunk of ugly code into GLib that will cause
compatibility headaches going forward if we ever need to change it.
Let's turn this around: i can see that with your gdbus design requiring
us to remarshall everything to gvaraint makes things a lot easier for
you, but it puts the work on us to do the remarshalling. If we now
conversely ask you to smply remarshall the driver msgs differently, then
you tell us that that wouldn't be dbus anymore... Jeezus...
This is not "simply remarshalling", as I mentioned above.
I'm not arguing that what you've done here is not better than D-Bus --
it clearly is; but it's different. I'm really starting to think a good
way forward might be to get people to opt-in to this new API knowing
that there are compatibility hitches that they'll have to deal with as
they do so. On systems that don't have kdbus, or in the event that we
cannot support it (network transparency, for example) you'd get an
oldschool dbus-1 connection, but you would still be forbidden (by API
contract) from directly sending org.freedesktop.DBus messages on it.
If we present this as a new kind of bus, perhaps we'd call it a "user
bus".....
(and some new name for the system one as well, of course -- I feel a lot
less clever for that one)
It's possibly worth considering at that point if we even need the
bridge. We could just let the people who don't opt-in to the new bus
type connect to the oldschool dbus-1 daemon. The only problem here is
that it means that every given public protocol would need to have a
'flag day' to switch buses, and it might be nice to avoid that. On the
other hand, in some cases, having the additional clarity might be nice,
and it may also give people a natural opportunity to fix other issues
that they have in their various APIs.
At this moment the most important is find common approach to kdbus
userspace implementation. I know that kdbus is still quite young
project and still evolving, but it would be good to have some certain
points. IMHO kdbus support in libraries shouldn't be visible outside
gdbus/libdbus- library should hide all kdbus aspects and keep dbus-1
compatibility - app developers shouldn't really notice the difference.
Next, we have to ensure that all unmodified apps will continue to work
the way they currently do.
Now we should also keep this discussion focused on technical solutions
rather than some "politics" (drop the gvariant and speak only dbus1
marshalling again or not?).
Cheers
Thanks,
--
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
