[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-dbus
Subject: Re: Starting the kdbus discussions
From: Ted Gould <ted () gould ! cx>
Date: 2014-01-09 15:21:55
Message-ID: 1389280915.2809.11.camel () roku
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
[Attachment #4 (multipart/alternative)]
On Wed, 2014-01-08 at 11:15 -0800, Marcel Holtmann wrote:
+AD4 let me give a simple analogy here. You are also not sending HTTP
+AD4 headers along with your TCP/IP socket. So neither should kdbus require
+AD4 any extra metadata that is not needed to transport payload. At the end
+AD4 of the day kdbus is a routing protocol to move messages from process A
+AD4 to process B. It needs enough information to do exactly this and
+AD4 nothing more.
I think that aligns with the naming issue that Greg pointed out. What
would be expected from something called +ACI-kdbus+ACI would be different t=
han
something called +ACI-kgenericbus+ACI. Likewise if the kernel module was
+ACI-khttp+ACI you'd expect a different relationship between headers and
payload than in +ACI-ktcp+ACI.
So, it seems to me that there are a lot of confusion created by the
language being used. My current understanding is that +ACI-kdbus+ACI is
designed to be a generic bus functionality in the kernel. Systemd then
implements a dbus-like (perhaps dbus v2) protocol over that generic bus
functionality. In theory, other buses could use that same generic
functionality if they so choose. So what Lennart started this thread
with is to add to the DBus spec +ACI-How to represent DBus on kdbus+ACI jus=
t
like the current spec is +ACI-How to represent DBus over sockets.+ACI Plea=
se
correct me if I'm wrong.
Ted
[Attachment #7 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
On Wed, 2014-01-08 at 11:15 -0800, Marcel Holtmann wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
let me give a simple analogy here. You are also not sending HTTP headers along \
with your TCP/IP socket. So neither should kdbus require any extra metadata that is \
not needed to transport payload. At the end of the day kdbus is a routing protocol to \
move messages from process A to process B. It needs enough information to do exactly \
this and nothing more.<BR> </BLOCKQUOTE>
<BR>
I think that aligns with the naming issue that Greg pointed out. What would be \
expected from something called "kdbus" would be different than something \
called "kgenericbus". Likewise if the kernel module was \
"khttp" you'd expect a different relationship between headers and payload \
than in "ktcp".<BR> <BR>
So, it seems to me that there are a lot of confusion created by the language being \
used. My current understanding is that "kdbus" is designed to be a \
generic bus functionality in the kernel. Systemd then implements a dbus-like \
(perhaps dbus v2) protocol over that generic bus functionality. In theory, \
other buses could use that same generic functionality if they so choose. So \
what Lennart started this thread with is to add to the DBus spec "How to \
represent DBus on kdbus" just like the current spec is "How to represent \
DBus over sockets." Please correct me if I'm wrong.<BR> <BR>
Ted<BR>
<BR>
</BODY>
</HTML>
["signature.asc" (application/pgp-signature)]
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic