Date: Tue, 12 Jan 2016 22:08:01 -0500 From: Mark Heily <mark@heily.com> To: Hubbard Jordan <jkh@ixsystems.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <CAGfo=8mBhCPUH8cxmo2z_GDUfknojSnyUTyBC6Wzk=BR=oA%2Big@mail.gmail.com> In-Reply-To: <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> References: <5687D3A9.5050400@NTLWorld.com> <CAGfo=8kXzNVKy9gx0jkME4iRRyrgrsfpPnW3nYrZC0gysapPcg@mail.gmail.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <alpine.BSF.2.20.1601081020270.34827@nog2.angryox.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 12, 2016 at 10:59 AM, Hubbard Jordan <jkh@ixsystems.com> wrote: > >> On Jan 12, 2016, at 4:59 AM, Konstantin Belousov <kostikbel@gmail.com> w= rote: >> >> I highly recommend to Google for "Mach IPC sucks" if reader is really in= terested. > > And here we return to the usual trap=E2=80=A6 > > =E2=80=9CMach IPC sucks!=E2=80=9D > > =E2=80=9COK. What do you propose that will address all of the same conce= rns?=E2=80=9D > > =E2=80=9Cdbus!=E2=80=9D > > =E2=80=9C*Sigh*. You haven=E2=80=99t even looked at the two technologies= in any depth, have you? Go read the dbus wikipedia page, at least! Unix = domain sockets underneath, no kernel<->userland communication path, no trus= ted IPC mechanism, no support for large messages=E2=80=A6=E2=80=9D > > =E2=80=9COK, so something new!! We should totally create an IPC for the = New Millennium!=E2=80=9D > > =E2=80=9CThat would be you then? Where=E2=80=99s your white paper? Wher= e=E2=80=99s your reference implementation?=E2=80=9D > > <crickets> > > Sorry. Been there, had this debate, and while it=E2=80=99s always extrem= ely easy to fling poop at an existing mechanism, it turns out it=E2=80=99s = so much harder to actually *create an alternative* that this kind of discus= sion only serves to throw cold water on evolution (=E2=80=9Cthe perfect bei= ng the enemy of the good enough=E2=80=9D) and the end-result is that evolut= ion does not occur. > > You're right in that DBus is not a great solution, and I think we can do better. I've gone ahead and created a general-purpose IPC library that is a plausible alternative to Mach IPC. Here's the code: https://github.com/mheily/libipc It is not a bus, and it is not object-oriented. Instead, it tries to make calling a remote function as easy and seamless as calling a local function. I was planning on hacking on it for a few more weeks before announcing it, but it seems very relevant to the discussion we are having today. It's built on top of Unix-domain sockets, and includes an IDL compiler that takes a reasonably simple YAML file and generates the boring code that allows programs to do structured IPC without worrying about serialization and bootstrapping and all of the underlying protocol issues. You've raised some objections to Unix-domain sockets, which I'd like to respond to. I'll quote from the slide in your presentation about Unix-domain sockets: ------------------------------------------------------------ > > > What can Mach ports do that Unix domain sockets can't? > > Separate namespace for services (doesn't rely on file system naming or > permissions) > This is generally a bad thing, IMHO. Filesystem permissions are a good way to apply security rules to an object, and they are a highly standard and well understood concept. If you need more than the traditional user/group/other support, you can supplement this with POSIX ACLs. Using the filesystem as a way to coordinate activity is a perfectly natural thing to do, and only has a disadvantage in a small corner case (where the system is in the process of booting up and the filesystem is not mounted). Right now, there is no need to perform IPC in the early part of the boot process. A machine where the root filesystem is not mounted read/write is basically unusable, and the solution is to mount the filesystem ASAP before starting any services that rely on IPC. > > Message boundaries > Not true. You have to provide your own semantics for finding the message boundaries, but it is totally possible to send messages across Unix-domain sockets. > > Kernel as peer > This is true, but not there are other ways for userspace to communicate with the kernel, such as syscalls and ioctl. Monolithic kernels don't use message passing, so we aren't missing out on much by not having this feature. > > Pre-existing well defined RPC interface > If Mach has such a great RPC interface, why do we need to hide it behind another abstraction layer like XPC? The existence of a thing is not necessarily an argument for it being the right tool for the job. > > Receive messages directly in call to kevent() > This is a "nice to have" performance optimization. We can live without it. > > OOL (out of line) messages (arbitrarily sized with zero copy for large me= ssages) > You can do zero-copy over Unix-domain sockets by sending a file descriptor across the socket that is backed by an anonymous region of memory created with mmap(2). To get the out-of-line behavior, all you need are two Unix-domain sockets; one acting as the control channel, and the other as the data channel. > > Port send rights - can only send to a port for which the process has expl= icitly > received the right to send > Unix-domain sockets have file permissions that control access. This is functionally equivalent to "port send rights", right? > > Provenance - Yes, PROVENANCE, receiver can have the kernel append an audi= t > trailer containing full set of credentials of sender > Unix-domain sockets allow you retrieve UID, GID, and PID of the client process. Unless you mean something different by "PROVENANCE", this is all the information you really need to make security decisions in the current Unix security model. ------------------------------------------------------------ So the TL;DR is that you can use Unix-domain sockets to do most of what Mach IPC provides. There are some major benefits to using sockets, such as the fact that are portable and relatively standardized across different Unix implementations (and even Windows). I think if you do a cost-benefit analysis between Mach and sockets, sockets win. Anyway, I'm planning to implement IPC in relaunchd using libipc, and relaunchd will be able to create the IPC service and launch the job "on demand" whenever a client attempts to connect to it. We've taken up a lot of airtime on this mailing list, so I invite anyone who is interested in IPC to join me on the libipc mailing list to discuss this further: https://groups.google.com/d/forum/libipc-devel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGfo=8mBhCPUH8cxmo2z_GDUfknojSnyUTyBC6Wzk=BR=oA%2Big>