From: Johannes Stezenbach <js@sig21.net> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: arnd@arndb.de, ebiederm@xmission.com, gnomes@lxorguk.ukuu.org.uk, teg@jklm.no, jkosina@suse.cz, luto@amacapital.net, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, daniel@zonque.org, dh.herrmann@gmail.com, tixxdz@opendz.org Subject: Re: [PATCH v3 00/13] Add kdbus implementation Date: Tue, 20 Jan 2015 14:24:37 +0100 [thread overview] Message-ID: <20150120132437.GB7545@sig21.net> (raw) In-Reply-To: <20150120112609.GA17198@kroah.com> On Tue, Jan 20, 2015 at 07:26:09PM +0800, Greg Kroah-Hartman wrote: > On Tue, Jan 20, 2015 at 11:57:12AM +0100, Johannes Stezenbach wrote: > > > > So I did some googling and found in QNX servers create a channel > > to receive messages, and clients connect to this channel. > > Multiple clients can connect to the channel. > > Hence, a bus :) > > > But it is not a bus -- no multicast/broadcast, and no name > > service or policy rules like D-Bus has. To me it looks > > to be similar in functionality to UNIX domain sockets. > > It's not as complex as D-Bus, but it's still subscribing to things and > getting messages. Apparently you don't read what I write, probably you're not interested in this discussion anymore... QNX uses the term "channel" but it does not refer to a bus or subscription facility, it is more like a socket in listening state. > > My guess is that the people porting from QNX were just confused > > and their use of D-Bus was in error. Maybe they should've used > > plain sockets, capnproto, ZeroMQ or whatever. > > I tend to trust that they knew what they were doing, they wouldn't have > picked D-Bus for no good reason. The automotive developers I had the pleasure to work with would use anything which is available via a mouse click in the commercial Embedded Linux SDK IDE of their choice :) Let's face it: QNX has a single IPC solution while Linux has a confusing multitude of possibilities. > > Well, IMHO you got it backwards. Before adding a complex new IPC > > API to the kernel you should do the homework and gather some > > evidence that there will be enough users to justify the addition. > > systemd wants this today for early boot. It will remove lots of code > and enable a lot of good things to happen. The first email in this > thread describes this quite well, is that not sufficient? The first mail in this thread doesn't even mention systemd, instead it has a lot of "marketing" buzzwords. Of course it is no secret that systemd is the driving force behind kdbus, but no public record exists to explain why kdbus was chosen and designed the way it is, what alternatives were considered and rejected etc. (or if there is, please send a link) > > FWIW, my gut feeling was that the earlier attempts to add a new > > IPC primitve like multicast UNIX domain sockets > > http://thread.gmane.org/gmane.linux.kernel/1255575/focus=1257999 > > were a much saner approach. But now I think the comments > > from this old thread have not been addressed, instead the > > new approach just made the thing more complex and > > put in ipc/ instead of net/ to bypass the guards. > > Not at all, the networking maintainers said that that proposal was not > acceptable to them at all and it should not be done in the networking > stack at all. So this was solution was created instead, which provides > a lot more things than the old networking patches did, which shows that > the networking developers were right to reject it. Please read the gmane thread to the end. It seems there were several indications that D-Bus can be improved in userspace using existing kernel facilities. Havoc Pennington's mail I quoted in my first response also contains some hints about it. I have no idea if any of this has ever been pursued. While adding complexity to critical net/ code paths is probematic and a good reason to reject it, this was not the only reason, the major one being "not neccessary". Thanks, Johannes
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Stezenbach <js-FF7aIK3TAVNeoWH0uzbU5w@public.gmane.org> To: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> Cc: arnd-r2nGTMty4D4@public.gmane.org, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org, gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org, teg-B22kvLQNl6c@public.gmane.org, jkosina-AlSwsSmVLrQ@public.gmane.org, luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org, dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, tixxdz-Umm1ozX2/EEdnm+yROfE0A@public.gmane.org Subject: Re: [PATCH v3 00/13] Add kdbus implementation Date: Tue, 20 Jan 2015 14:24:37 +0100 [thread overview] Message-ID: <20150120132437.GB7545@sig21.net> (raw) In-Reply-To: <20150120112609.GA17198-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> On Tue, Jan 20, 2015 at 07:26:09PM +0800, Greg Kroah-Hartman wrote: > On Tue, Jan 20, 2015 at 11:57:12AM +0100, Johannes Stezenbach wrote: > > > > So I did some googling and found in QNX servers create a channel > > to receive messages, and clients connect to this channel. > > Multiple clients can connect to the channel. > > Hence, a bus :) > > > But it is not a bus -- no multicast/broadcast, and no name > > service or policy rules like D-Bus has. To me it looks > > to be similar in functionality to UNIX domain sockets. > > It's not as complex as D-Bus, but it's still subscribing to things and > getting messages. Apparently you don't read what I write, probably you're not interested in this discussion anymore... QNX uses the term "channel" but it does not refer to a bus or subscription facility, it is more like a socket in listening state. > > My guess is that the people porting from QNX were just confused > > and their use of D-Bus was in error. Maybe they should've used > > plain sockets, capnproto, ZeroMQ or whatever. > > I tend to trust that they knew what they were doing, they wouldn't have > picked D-Bus for no good reason. The automotive developers I had the pleasure to work with would use anything which is available via a mouse click in the commercial Embedded Linux SDK IDE of their choice :) Let's face it: QNX has a single IPC solution while Linux has a confusing multitude of possibilities. > > Well, IMHO you got it backwards. Before adding a complex new IPC > > API to the kernel you should do the homework and gather some > > evidence that there will be enough users to justify the addition. > > systemd wants this today for early boot. It will remove lots of code > and enable a lot of good things to happen. The first email in this > thread describes this quite well, is that not sufficient? The first mail in this thread doesn't even mention systemd, instead it has a lot of "marketing" buzzwords. Of course it is no secret that systemd is the driving force behind kdbus, but no public record exists to explain why kdbus was chosen and designed the way it is, what alternatives were considered and rejected etc. (or if there is, please send a link) > > FWIW, my gut feeling was that the earlier attempts to add a new > > IPC primitve like multicast UNIX domain sockets > > http://thread.gmane.org/gmane.linux.kernel/1255575/focus=1257999 > > were a much saner approach. But now I think the comments > > from this old thread have not been addressed, instead the > > new approach just made the thing more complex and > > put in ipc/ instead of net/ to bypass the guards. > > Not at all, the networking maintainers said that that proposal was not > acceptable to them at all and it should not be done in the networking > stack at all. So this was solution was created instead, which provides > a lot more things than the old networking patches did, which shows that > the networking developers were right to reject it. Please read the gmane thread to the end. It seems there were several indications that D-Bus can be improved in userspace using existing kernel facilities. Havoc Pennington's mail I quoted in my first response also contains some hints about it. I have no idea if any of this has ever been pursued. While adding complexity to critical net/ code paths is probematic and a good reason to reject it, this was not the only reason, the major one being "not neccessary". Thanks, Johannes
next prev parent reply other threads:[~2015-01-20 13:25 UTC|newest] Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-16 19:16 [PATCH v3 00/13] Add kdbus implementation Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 01/13] kdbus: add documentation Greg Kroah-Hartman 2015-01-20 13:53 ` Michael Kerrisk (man-pages) 2015-01-20 13:53 ` Michael Kerrisk (man-pages) 2015-01-20 14:31 ` David Herrmann 2015-01-20 14:31 ` David Herrmann 2015-01-20 14:42 ` Josh Boyer 2015-01-20 14:42 ` Josh Boyer 2015-01-20 14:53 ` Djalal Harouni 2015-01-20 14:53 ` Djalal Harouni 2015-01-20 16:08 ` Johannes Stezenbach 2015-01-20 17:00 ` David Herrmann 2015-01-20 17:00 ` David Herrmann 2015-01-20 22:00 ` Johannes Stezenbach 2015-01-20 22:00 ` Johannes Stezenbach 2015-01-21 10:28 ` Michael Kerrisk (man-pages) 2015-01-21 10:28 ` Michael Kerrisk (man-pages) 2015-01-20 18:23 ` Daniel Mack 2015-01-20 18:23 ` Daniel Mack 2015-01-21 10:32 ` Michael Kerrisk (man-pages) 2015-01-21 10:32 ` Michael Kerrisk (man-pages) 2015-01-21 15:19 ` Theodore Ts'o 2015-01-21 15:19 ` Theodore Ts'o 2015-01-21 16:58 ` Daniel Mack 2015-01-21 16:58 ` Daniel Mack 2015-01-22 10:18 ` Michael Kerrisk (man-pages) 2015-01-22 10:18 ` Michael Kerrisk (man-pages) 2015-01-22 13:46 ` David Herrmann 2015-01-22 13:46 ` David Herrmann 2015-01-22 14:49 ` Austin S Hemmelgarn 2015-01-23 16:08 ` Greg Kroah-Hartman 2015-01-26 14:46 ` Michael Kerrisk (man-pages) 2015-01-26 14:46 ` Michael Kerrisk (man-pages) 2015-01-27 15:05 ` David Herrmann 2015-01-27 15:05 ` David Herrmann 2015-01-27 16:03 ` Andy Lutomirski 2015-01-27 16:03 ` Andy Lutomirski 2015-01-29 8:53 ` Daniel Mack 2015-01-29 8:53 ` Daniel Mack 2015-01-29 11:25 ` Andy Lutomirski 2015-01-29 11:42 ` Daniel Mack 2015-01-29 12:09 ` Andy Lutomirski 2015-02-02 9:34 ` Daniel Mack 2015-02-02 9:34 ` Daniel Mack 2015-02-02 20:12 ` Andy Lutomirski 2015-02-02 20:12 ` Andy Lutomirski 2015-02-03 10:09 ` Daniel Mack 2015-02-03 10:09 ` Daniel Mack 2015-02-04 0:41 ` Andy Lutomirski 2015-02-04 0:41 ` Andy Lutomirski 2015-02-04 2:47 ` Eric W. Biederman 2015-02-04 2:47 ` Eric W. Biederman 2015-02-04 3:14 ` Greg Kroah-Hartman 2015-02-04 3:14 ` Greg Kroah-Hartman 2015-02-04 6:30 ` Eric W. Biederman 2015-02-04 6:30 ` Eric W. Biederman 2015-02-04 23:03 ` Andy Lutomirski 2015-02-04 23:03 ` Andy Lutomirski 2015-02-05 0:16 ` David Herrmann 2015-02-08 16:54 ` Andy Lutomirski 2015-02-08 16:54 ` Andy Lutomirski 2015-01-27 18:03 ` Michael Kerrisk (man-pages) 2015-01-27 18:03 ` Michael Kerrisk (man-pages) 2015-01-23 11:47 ` Michael Kerrisk (man-pages) 2015-01-23 11:47 ` Michael Kerrisk (man-pages) 2015-01-23 15:54 ` Greg Kroah-Hartman 2015-01-23 15:54 ` Greg Kroah-Hartman 2015-01-26 14:42 ` Michael Kerrisk (man-pages) 2015-01-26 14:42 ` Michael Kerrisk (man-pages) 2015-01-26 15:26 ` Tom Gundersen 2015-01-26 16:44 ` christoph Hellwig 2015-01-26 16:44 ` christoph Hellwig 2015-01-26 16:45 ` Michael Kerrisk (man-pages) 2015-01-27 15:23 ` David Herrmann 2015-01-27 17:53 ` Michael Kerrisk (man-pages) 2015-01-27 18:14 ` Daniel Mack 2015-01-27 18:14 ` Daniel Mack 2015-01-28 10:46 ` Michael Kerrisk (man-pages) 2015-01-20 13:58 ` Michael Kerrisk (man-pages) 2015-01-20 13:58 ` Michael Kerrisk (man-pages) 2015-01-20 17:50 ` Daniel Mack 2015-01-21 8:57 ` Michael Kerrisk (man-pages) 2015-01-21 8:57 ` Michael Kerrisk (man-pages) 2015-01-21 9:07 ` Daniel Mack 2015-01-21 9:07 ` Michael Kerrisk (man-pages) 2015-01-21 9:07 ` Michael Kerrisk (man-pages) 2015-01-21 9:12 ` Daniel Mack 2015-01-21 9:12 ` Daniel Mack 2015-01-23 6:28 ` Ahmed S. Darwish 2015-01-23 6:28 ` Ahmed S. Darwish 2015-01-23 13:19 ` Greg Kroah-Hartman 2015-01-23 13:29 ` Greg Kroah-Hartman 2015-01-23 13:29 ` Greg Kroah-Hartman 2015-01-25 3:30 ` Ahmed S. Darwish 2015-01-25 3:30 ` Ahmed S. Darwish 2015-01-16 19:16 ` [PATCH 02/13] kdbus: add header file Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 03/13] kdbus: add driver skeleton, ioctl entry points and utility functions Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 04/13] kdbus: add connection pool implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 05/13] kdbus: add connection, queue handling and message validation code Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 06/13] kdbus: add node and filesystem implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 07/13] kdbus: add code to gather metadata Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 08/13] kdbus: add code for notifications and matches Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 09/13] kdbus: add code for buses, domains and endpoints Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 10/13] kdbus: add name registry implementation Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 11/13] kdbus: add policy database implementation Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 12/13] kdbus: add Makefile, Kconfig and MAINTAINERS entry Greg Kroah-Hartman 2015-01-16 19:16 ` Greg Kroah-Hartman 2015-01-16 19:16 ` [PATCH 13/13] kdbus: add selftests Greg Kroah-Hartman 2015-01-16 22:07 ` [PATCH v3 00/13] Add kdbus implementation Josh Boyer 2015-01-16 22:07 ` Josh Boyer 2015-01-16 22:18 ` Greg Kroah-Hartman 2015-01-17 0:26 ` Daniel Mack 2015-01-17 0:26 ` Daniel Mack 2015-01-17 0:41 ` Josh Boyer 2015-01-17 0:41 ` Josh Boyer 2015-01-19 18:06 ` Johannes Stezenbach 2015-01-19 18:06 ` Johannes Stezenbach 2015-01-19 18:38 ` Greg Kroah-Hartman 2015-01-19 20:19 ` Johannes Stezenbach 2015-01-19 20:19 ` Johannes Stezenbach 2015-01-19 20:31 ` Greg Kroah-Hartman 2015-01-19 23:38 ` Johannes Stezenbach 2015-01-19 23:38 ` Johannes Stezenbach 2015-01-20 1:13 ` Greg Kroah-Hartman 2015-01-20 1:13 ` Greg Kroah-Hartman 2015-01-20 10:57 ` Johannes Stezenbach 2015-01-20 11:26 ` Greg Kroah-Hartman 2015-01-20 11:26 ` Greg Kroah-Hartman 2015-01-20 13:24 ` Johannes Stezenbach [this message] 2015-01-20 13:24 ` Johannes Stezenbach 2015-01-20 14:12 ` Michael Kerrisk (man-pages) 2015-01-26 21:32 ` One Thousand Gnomes 2015-01-26 21:32 ` One Thousand Gnomes 2015-01-19 18:33 ` Johannes Stezenbach 2015-01-19 18:33 ` Johannes Stezenbach 2015-01-20 14:05 ` Michael Kerrisk (man-pages) 2015-01-20 14:05 ` Michael Kerrisk (man-pages) 2015-01-20 14:15 ` Michael Kerrisk (man-pages)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20150120132437.GB7545@sig21.net \ --to=js@sig21.net \ --cc=arnd@arndb.de \ --cc=daniel@zonque.org \ --cc=dh.herrmann@gmail.com \ --cc=ebiederm@xmission.com \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=gregkh@linuxfoundation.org \ --cc=jkosina@suse.cz \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=teg@jklm.no \ --cc=tixxdz@opendz.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.