Date: Tue, 12 Jan 2016 14:59:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Hubbard Jordan <jkh@ixsystems.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <20160112125948.GH3625@kib.kiev.ua> In-Reply-To: <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 11, 2016 at 11:53:59PM -0800, Hubbard Jordan wrote: > The fact is, IPC on Unix has traditionally sucked and nobody has yet to provide an alternative to Mach IPC which ticks all the same boxes. A hierarchical namespace that can be used to create privilege domains (providing a very key ability to control who can talk to who) - Check. Supports service discovery as an intrinsic property without the presence of a filesystem (e.g. pre-mountroot) - Check. Provides audit trailers in every message that make it possible to validate who you???re talking to and create ???trusted delegates??? for certain services that would otherwise be forced to be in the kernel - Check. The ability to pass shared memory descriptors out-of-band for large messages - Check. That???s not even a full list, but it covers some features that OS X and iOS use in many different ways to good effect. > > Believe me, if there was something better, with the right high-level semantics (which alternatives like L4 IPC do not provide) combined with low-level capabilities like allowing the kernel to talk to userspace using the very same IPC mechanisms, we???d use it. Since there isn???t, we stick things like XPC (which NextBSD is doing a clean-room implementation of) on top of Mach IPC to avoid the horror of using MIG and doing RPC programming from the 1980s, and we spend the time we???d otherwise have to spend creating an entirely new and unproven IPC mechanism (which might very well fail to impress anyone after we finished) and focus instead on creating the services that use it. Seems like a reasonable example of ???code re-use??? to me! > Anybody who used Win32 and even whispered a word about bloated and verbose interfaces that require two screens of boilerplate to do trivial things, would be much more amazed by Mach IPC. I highly recommend to Google for "Mach IPC sucks" if reader is really interested. Although, the main complaint you would find there is about extreme overhead, which is mostly due to unconditional support for the all the hundreds features partially listed above. Microkernels failed for many reasons, and uglyness of the basic underlying mechanics in the most advanced and popular specimen a was non-trivial factor. The theme of great softwares and codes from past which did not survived due to (conspiracy|underrate|worse is better) is quite popular and not debunked since proponents always point out perceived goodies and are silent about suck points. Because nobody used (and can try the stuff for real), the claims stay. See the memories of things like SunView, Display Postscript, etc. Fortunately people do not praise Corba yet, at least not with the straight face, but I am waiting. Even mentioned Doors are better then Mach IPC, but still dead, I think app space is completely consumed now by dbus or http-based hand-rolled protocols.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160112125948.GH3625>