Starting the kdbus discussions

[Lennart Poettering]

On Wed, 08.01.14 10:23, Jamie Strandboge (jamie at canonical.com) wrote:

> In an effort to keep things constructive, as Tyler said, we're talking about
> moving the line ever so slightly between kdbus metadata and payload so that
> kdbus retains some of the existing headers in the metadata and is therefore more
> in line with the current D-Bus specification[1]. 

I indeed missed the part in the dbus spec where it says how much of the
message the kernel should know about when kdbus used as transports...

> This shouldn't greatly complicate things and systemd, Portals,
> SElinux, etc should be able to just ignore these headers if they
> choose. We'd be delighted to work with kdbus upstream to make this
> happen, with code if people would review and seriously consider it.

We'd be delighted to take your contributions on other things, but to
this one we have to say no, because we technically disagree with
it. Sorry.

> Greg had an interesting comment: 'Is the name of the kernel module confusing
> people?  We can rename it to be "kbus" if the "d" is causing problems.' Indeed,
> but why then are kdbus upstream sending this to dbus at lists.freedesktop.org and
> asking to discuss "the details and what this means for the dbus spec"?

Riiight... So you are granting us the choice between two options: a) go
away, or b) agree to any hack you propose.

> Let me be very clear, we want to use kdbus and to participate in its development
> and we want to work with upstream to make kdbus something that the wider D-Bus
> community can use. At this point, I was going to write, "how can we make this
> happen?" since we seemed to be at an impasse. However, based on Greg's last
> email, it sounds like patches will be thoughtfully considered and that there
> actually is a path forward to work together on the best technical solution.

You already got a clear answer on this specific request to change the
kdbus design, and that was "no". That's a specific answer to a specific
request. 

We are certianly interested in Canonical's contributions to kdbus, but
we simply technically disagree on this specific request of making the
kernel aware of the full dbus userspace header. You have to accept
that. COntribute other patches, but one that adds more message kernel
headers will not be accepted.

I mean, do you really expect that if you moved the HTTP header fields
like the URL or HTTP method into the TCP header and try to sell that to
the Linux IP stack guys, that you'd get any other answer then "No" from
them?

Lennart

-- 
Lennart Poettering, Red Hat