Date: Tue, 12 Jan 2016 23:05:18 -0800 From: Hubbard Jordan <jkh@ixsystems.com> To: Mark Heily <mark@heily.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <66E766F4-66D5-41E1-B6E7-18E218B3711F@ixsystems.com> 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
> On Jan 12, 2016, at 7:08 PM, Mark Heily <mark@heily.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?66E766F4-66D5-41E1-B6E7-18E218B3711F>