Date: Wed, 13 Jan 2016 08:17:46 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Mark Heily <mark@heily.com> Cc: Hubbard Jordan <jkh@ixsystems.com>, Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <F9EED7D5-0FFB-4831-88A4-609246B0C111@rdsor.ro> 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
>=20 > This is generally a bad thing, IMHO. Filesystem permissions are a > good way to apply security rules to an object,=20 It is a good thing to have a hierarchical namespace which do not depend = on the filesystem. Port right are also a good way to apply security rules to objects.=20 > Using the filesystem as a way to coordinate activity is a perfectly > natural thing to do Why would be so natural ?=20 > 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. Yet kernel events of interest may happen before a filesystem is = mounted.=20 > If Mach has such a great RPC interface, why do we need to hide it = behind > another abstraction layer like XPC? The usual reason we build abstractions over other abstractions. Same = reason you created a RPC library. Ask yourself why you created an rpc abstraction = on top of unix=20 domain sockets, and you will get the answer. > Monolithic kernels don't use > message passing, so we aren't missing out on much by not having this > feature. This is dogmatic and it misses the point of why kernel endpoints are = needed.=20 The situation has nothing to do with monolithic and microkernel = designs.=20 It allows any kernel component to pass messages to arbitrary = destinations. It is a generalised mechanism like devd. Good luck generalising that = with unix sockets. > 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). And why is portability of such a subsystem relevant ? Its not like = anybody will jump to port launchd Windows :P Or even Linux. Nobody will care. >>=20 >> Receive messages directly in call to kevent() >>=20 >=20 > This is a "nice to have" performance optimization. We can live without = it. Tautology. We can live without sendfile(2). We can also live without = kqueue/kevent(2) themselves. We could have lived with DOS. > On 13 Jan 2016, at 05:08, Mark Heily <mark@heily.com> wrote: >=20 > On Tue, Jan 12, 2016 at 10:59 AM, Hubbard Jordan <jkh@ixsystems.com = <mailto:jkh@ixsystems.com>> wrote: >>=20 >>> On Jan 12, 2016, at 4:59 AM, Konstantin Belousov = <kostikbel@gmail.com> wrote: >>>=20 >>> I highly recommend to Google for "Mach IPC sucks" if reader is = really interested. >>=20 >> And here we return to the usual trap=E2=80=A6 >>=20 >> =E2=80=9CMach IPC sucks!=E2=80=9D >>=20 >> =E2=80=9COK. What do you propose that will address all of the same = concerns?=E2=80=9D >>=20 >> =E2=80=9Cdbus!=E2=80=9D >>=20 >> =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 trusted IPC mechanism, no support for large = messages=E2=80=A6=E2=80=9D >>=20 >> =E2=80=9COK, so something new!! We should totally create an IPC for = the New Millennium!=E2=80=9D >>=20 >> =E2=80=9CThat would be you then? Where=E2=80=99s your white paper? = Where=E2=80=99s your reference implementation?=E2=80=9D >>=20 >> <crickets> >>=20 >> Sorry. Been there, had this debate, and while it=E2=80=99s always = extremely 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 discussion only serves to throw cold water on evolution = (=E2=80=9Cthe perfect being the enemy of the good enough=E2=80=9D) and = the end-result is that evolution does not occur. >>=20 >>=20 >=20 > You're right in that DBus is not a great solution, and I think we can = do > better. >=20 > I've gone ahead and created a general-purpose IPC library that is a > plausible alternative to Mach IPC. Here's the code: >=20 > https://github.com/mheily/libipc <https://github.com/mheily/libipc>; >=20 > 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. >=20 > 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. >=20 > 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: >=20 > ------------------------------------------------------------ >=20 >>=20 >>=20 >> What can Mach ports do that Unix domain sockets can't? >>=20 >> Separate namespace for services (doesn't rely on file system naming = or >> permissions) >>=20 >=20 > 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. >=20 > 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). >=20 > 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. >=20 >>=20 >> Message boundaries >>=20 >=20 > 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. >=20 >>=20 >> Kernel as peer >>=20 >=20 > 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. >=20 >>=20 >> Pre-existing well defined RPC interface >>=20 >=20 > 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. >=20 >>=20 >> Receive messages directly in call to kevent() >>=20 >=20 > This is a "nice to have" performance optimization. We can live without = it. >=20 >>=20 >> OOL (out of line) messages (arbitrarily sized with zero copy for = large messages) >>=20 >=20 > 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). >=20 > 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. >=20 >>=20 >> Port send rights - can only send to a port for which the process has = explicitly >> received the right to send >>=20 >=20 > Unix-domain sockets have file permissions that control access. This is > functionally > equivalent to "port send rights", right? >=20 >>=20 >> Provenance - Yes, PROVENANCE, receiver can have the kernel append an = audit >> trailer containing full set of credentials of sender >>=20 >=20 > 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. >=20 > ------------------------------------------------------------ >=20 > 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. >=20 > 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. >=20 > 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: >=20 > https://groups.google.com/d/forum/libipc-devel = <https://groups.google.com/d/forum/libipc-devel>; > _______________________________________________ > freebsd-hackers@freebsd.org <mailto:freebsd-hackers@freebsd.org> = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers = <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>; > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org = <mailto:freebsd-hackers-unsubscribe@freebsd.org>"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9EED7D5-0FFB-4831-88A4-609246B0C111>