Starting the kdbus discussions

[Tyler Hicks]

On 2014-01-08 07:04:48, Greg KH wrote:
> On Wed, Jan 08, 2014 at 08:12:43AM -0500, Marc Deslauriers wrote:
> > On 14-01-08 03:51 AM, Lennart Poettering wrote:
> > > On Tue, 07.01.14 15:24, Tyler Hicks (tyhicks at canonical.com) wrote:
> > > 
> > >> Hi Lennart! I've added Greg to cc since John Johansen and I spoke with
> > >> him about this in a hallway at Plumbers last year.
> > >>
> > >> On 2014-01-02 18:08:42, Lennart Poettering wrote:
> > >>> I am sorry, but to make this very clear: this is explicitly not an
> > >>> option. There will not be a payload parser for kdbus in the kernel, as
> > >>> long as the four developers who are working on it have any say. The
> > >>> entire design is based on the concept that the payload is irrelevant to
> > >>> the kernel, and routing is done only according to the metadata we
> > >>> attach. This is a fundamental design decision of kdbus, and the four of
> > >>> us (Kay, Daniel, Greg and I) will refuse this.
> > >>
> > >> I agree that parsing the payload in the kernel is not something that we
> > >> should do. However, I do think that there are some important metadata
> > >> fields hidden away in the opaque sd_bus_message that should be exposed
> > >> to the kernel by way of moving them to the kdbus_msg.
> > >>
> > >> I'm proposing that the following fields be moved to the kdbus_msg:
> > >>
> > >>  - message type
> > >>  - destination
> > >>  - sender
> > > 
> > > These three you have anyway, in one way or another. (or can mostly
> > > reconstruct from the data available to the kernel, since the kernel can
> > > distuingish method calls from method replies and broadcast signals --
> > > though you cannot distuingish methods replies from method errors).
> > > 
> > >>  - path
> > >>  - interface
> > >>  - member
> > > 
> > > Nope. This is really not how this is supposed to work. These concepts
> > > are opaque to the kernel on purpose.
> > 
> > So you're not willing to change any of your design to cope with the community's
> > requirements?
> 
> A meta comment here.
> 
> That's not how development works.  Look at the Samsung developer's use
> of kdbus as an example of how to do things.  I kept telling them to not
> use kdbus yet as it wasn't ready, but did they listen to me?  No, they
> went and used it, and then, when they had issues with the code, they
> sent patches resolving it for them.
> 
> Development works with code, not "could you please change your design to
> help with our single-use problem that isn't even implemented for dbus
> today".  Try implementing the above in the kdbus code and see how
> intrusive, and unneeded for the rest of the world to understand why we
> are objecting to this.  Maybe we are wrong, and it isn't, but we will
> never really know until you do the work...

That's a good point. I threw my proposal out there after Lennart invited
the discussion on kdbus but I should have made it clear that I fully
intended to do the work myself.

I'll start getting patches together and see if I hit any snags. I'll
also try my best to limit the added overhead on other kdbus users that
don't need this sort of functionality.

Thanks, Greg!

Tyler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140108/f2c2c50e/attachment.pgp>