From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R50XK-0003q9-5c for garchives@archives.gentoo.org; Sat, 17 Sep 2011 19:26:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A2DC221C156; Sat, 17 Sep 2011 19:26:29 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 3BCCE21C05B for ; Sat, 17 Sep 2011 19:24:39 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so5957754bkb.40 for ; Sat, 17 Sep 2011 12:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=tYbDNm9VFShM+SFKbSaF4z8Of1775WOcwODOLcNC8pg=; b=GoybVeQtQtGZKtEfW3OTZsQCVI3vVYGhX5xmU8E/ltBtBBXScpfCzHl7qCGlfVGGPv y2h7/SOGd/IJhqWz2Nywd2u20FGhUgvI2Bs/cSquLPQYyxDAtM0y3vgAQT0IQAz6sBy9 WAy+a8IbvxfIo5triYQIIapTdpA7wy32dB5IM= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.0.70 with SMTP id 6mr502110bka.258.1316287479296; Sat, 17 Sep 2011 12:24:39 -0700 (PDT) Received: by 10.204.155.79 with HTTP; Sat, 17 Sep 2011 12:24:39 -0700 (PDT) In-Reply-To: References: <20110912150248.GB3599@acm.acm> <1728923.nQPHW4UTlG@eve> <1495175.Z7uWjMfsve@eve> Date: Sat, 17 Sep 2011 15:24:39 -0400 Message-ID: Subject: Re: [gentoo-user] udev + /usr From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 49aacbdf7a920221fba853bab994146d On Sat, Sep 17, 2011 at 2:36 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Sat, Sep 17, 2011 at 11:41 AM, Michael Mol wrote: >> On Sat, Sep 17, 2011 at 10:50 AM, Canek Pel=C3=A1ez Vald=C3=A9s >>> I wo= uld like for you to be more specific about them. >> >> Sockets, be they UNIX domain sockets, IPv4 or IPv6. > [snip] >> Shared memory: > [snip] >> Pipes: > [snip] > > Yeah, but then you need to design, implement and debug a protocol > communication: what part of the wire speaks first, what does it says, > what are the valid responses, etc. > > And then, if other component wants to communicate, it has to learn > your little protocol. dbus standardize this. And it uses sockets, > shared memory and pipes as building blocks, I believe, Reasonable points, all, up to the term 'standardize'. How stable is the API= ? Apart from our discussions of dbus from a few weeks ago, that's most of what I know about it, quoted from the gpsd man page: USE WITH D-BUS On operating systems that support D-BUS, gpsd can be built to broadc= ast GPS fixes to D-BUS-aware applications. As D-BUS is still at a pre-1.= 0 stage, we will not attempt to document this interface here. Read the= gpsd source code to learn more. > >> Not sure what others there are, but those have existed longer than >> I've been alive, and been standard since the early 1990s. > > They are standard in the sense that they are a low level communication > standard API. An IPC is *way* more than that; =C2=A0dbus is an IPC, becau= se > then you have high level "objects" and "methods", no matter the > language of the two sides of the wire communicating, or even if the > objects live in the same computer or not. > > BTW, there *was* an standard that did everything dbus does: ORB, the > Object Request Broker. They tried to use that as IPC years ago, but is > so damn complicated to implement right they decided to better > implement a new standard. The standard is dbus. Interesting. I'd heard of ORB, even tried to play with it a bit, but the documentation I've found is terrible. Like a number of fields I've poked at, if you wan to understand how to do something, you have to do it, making for a tricky. That said, who is They, and who decided that The standard is D-Bus? > >> Progress is >> adding new functionality, not reimplementing existing functionality as >> new APIs on top of the existing functionality. > > I think you are wrong if you believe that dbus is just "existing > functionality as new APIs on top of the existing functionality". dbus > is a complete IPC system. Neither sockets, shared memory nor pipes are > an IPC, because they lack a well defined protocol. You *can* do the > same you do with dbus if you only use sockets/sharedmem/pipes, but > then you need to do it over and over and over again. Is like the > difference between assembler and C: you *can* do the same with both, > but that does not mean that is actually a good idea to only use > assembler. I take (and even accept) your points on D-Bus having more functionality than the three other IPC mechanisms I described. That said, I disagree that D-Bus is an inter-process control mechansim, but sockets, shm and pipes are not. To draw from networking terminology, sockets, shm and pipes could be seen as being on layers 2 and/or 3 of the OSI stack (shm and unix domain sockets being a definite layer 2, IP sockets being layer 3), and D-Bus represents a mixture of layers 3-5. An application may choose to use only layers 2-3 for IPC, or it may choose to use D-Bus. --=20 :wq