From owner-freebsd-hackers@freebsd.org Wed Jan 13 07:05:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B803A80D66 for ; Wed, 13 Jan 2016 07:05:21 +0000 (UTC) (envelope-from jkh@ixsystems.com) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F42D1189 for ; Wed, 13 Jan 2016 07:05:20 +0000 (UTC) (envelope-from jkh@ixsystems.com) X-ASG-Debug-ID: 1452668718-08ca042abd100d0002-P5m3U7 Received: from [10.11.111.236] (50-250-239-90-static.hfc.comcastbusiness.net [50.250.239.90]) by barracuda.ixsystems.com with ESMTP id wfaVbccPDfdRDjSa (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 23:05:19 -0800 (PST) X-Barracuda-Envelope-From: jkh@ixsystems.com X-Barracuda-AUTH-User: jkh@ixsystems.com X-Barracuda-Apparent-Source-IP: 50.250.239.90 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3117\)) Subject: Re: relaunchd: a portable clone of launchd From: Hubbard Jordan X-ASG-Orig-Subj: Re: relaunchd: a portable clone of launchd In-Reply-To: Date: Tue, 12 Jan 2016 23:05:18 -0800 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com> References: <5687D3A9.5050400@NTLWorld.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> To: Mark Heily X-Mailer: Apple Mail (2.3117) X-Barracuda-Connect: 50-250-239-90-static.hfc.comcastbusiness.net[50.250.239.90] X-Barracuda-Start-Time: 1452668719 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.26080 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:05:21 -0000 > On Jan 12, 2016, at 7:08 PM, Mark Heily wrote: >=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 Kudos for creating something for review, at least. It beats the usual = discussion-without-code and I won=E2=80=99t argue with the notion of = creating something new, though I would like to push back on at least a = few of the points you make about Mach IPC because they=E2=80=99re = important in understanding the full picture. >> Separate namespace for services (doesn't rely on file system naming = or >> permissions) >=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. I think this is pretty subjective. Speaking as someone who has used a = services namespace for a long time, I would argue the exact opposite = with probably equal amounts of conviction and justification. I come = down firmly on the side of the argument that says it's a good thing and = Filesystem permissions are a terrible way of applying security rules to = an object, particularly as they only provide very limited semantics. = All of the ACLs in the world won=E2=80=99t help you to create an = extensible security trailer that identifies multiple clients of a single = server in a unique way (pid/uid/gid is practically useless for this). = However, I can=E2=80=99t force you to walk in the shoes of an OS X = internals developer (or even offer you that opportunity) so we=E2=80=99re = back to subjective and dueling opinions on this again. > 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). That=E2=80=99s actually not a corner case on the software appliances = we=E2=80=99ve been creating lately. That=E2=80=99s the usual case. :) = You start out with a bootstrap MFS and then selectively mount ZFS = datasets and such on top of various locations that would like to have = more storage (like /var/tmp or /var/db). This makes locating your Unix = domain sockets a bit tricky. Again, this is not just hypothetical - = we=E2=80=99ve run into multiple problems where we wound up covering up = our own mongodb / syslog sockets and hilarity ensued until we realized = the problem and sorted it out.=20 Again, I clearly can=E2=80=99t convince you otherwise, but a service = discovery mechanism built-in to the kernel is awesome and to say =E2=80=9C= you don=E2=80=99t need it=E2=80=9D is a bit like someone telling you = that you don=E2=80=99t need to make whatever amount of money you=E2=80=99r= e making but should be happy working as a night clerk at 7-11. Who is = anyone to make that kind of assertion without background? :) > 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. Of course you can send messages over Unix-domain sockets. You can send = messages using a morse-code key and a Marconi spark-gap transmitter, for = that matter, but that doesn=E2=80=99t mean you don=E2=80=99t want = something else to take care of that for you. Mach IPC does, and = that=E2=80=99s all I meant on that slide. >> 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. Yes, and they all suck and/or are implemented completely ad-hoc on a = case-by-case basis (the routing socket comes to mind) rather than having = an architecture make them conform to some common design patterns, both = for existing and for new mechanisms. I dunno, but it sure seems to me = like you=E2=80=99re going to such lengths to hate on Mach IPC that = you=E2=80=99re willing to essentially argue against architecture, clean = abstraction boundaries, and pretty much anything anyone finds valuable = in order to hold such a strong position. It=E2=80=99s sort of = reminiscent of various arguments I=E2=80=99ve had with assembly bigots = that high level languages are just a waste of time and CPU cycles and = there=E2=80=99s absolutely nothing worth doing that can=E2=80=99t be = done in assembly. I mean sure, they=E2=80=99re not out-and-out WRONG, = but the entire argument seems silly in the extreme. - Jordan