relaunchd: a portable clone of launchd

[Chris H]

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 at heily.com> wrote

> On Tue, Jan 12, 2016 at 10:59 AM, Hubbard Jordan <jkh at ixsystems.com> wrote:
> >
> >> On Jan 12, 2016, at 4:59 AM, Konstantin Belousov <kostikbel at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"