[systemd-devel] bus driver on kdbus

Wed Apr 16 07:57:45 PDT 2014

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
l.skalski at samsung.com