Date: Tue, 12 Jan 2016 23:41:05 -0800 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <0bd51315419aa2179b4f8319560d5340@ultimatedns.net> In-Reply-To: <CAGfo=8mBhCPUH8cxmo2z_GDUfknojSnyUTyBC6Wzk=BR=oA%2Big@mail.gmail.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>, <CAGfo=8mBhCPUH8cxmo2z_GDUfknojSnyUTyBC6Wzk=BR=oA%2Big@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Mark. Apologies for top posting, but I just wanted to say thanks for sharing this. A quick look at it. It appears promising. In the very least -- interesting. ;) Thanks again! --Chris On Tue, 12 Jan 2016 22:08:01 -0500 Mark Heily <mark@heily.com> wrote > 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> > >> wrote: >> > >> I highly recommend to Google for "Mach IPC sucks" if reader is really > >> interested. > > > And here we return to the usual trap… > > > > “Mach IPC sucks!” > > > > “OK. What do you propose that will address all of the same concerns?” > > > > “dbus!” > > > > “*Sigh*. You haven’t 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 trusted IPC > > mechanism, no support for large messages…” > > > “OK, so something new!! We should totally create an IPC for the New > > Millennium!” > > > “That would be you then? Where’s your white paper? Where’s your > > reference implementation?” > > > <crickets> > > > > Sorry. Been there, had this debate, and while it’s always extremely easy > > to fling poop at an existing mechanism, it turns out it’s so much harder to > > actually *create an alternative* that this kind of discussion only serves to > > throw cold water on evolution (“the perfect being the enemy of the good > > enough”) and the end-result is that evolution 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 > > messages) > > > 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 > > explicitly 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 audit > > 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 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0bd51315419aa2179b4f8319560d5340>