nosh version 1.9
Jordan Hubbard
jkh at mail.turbofuzz.com
Thu Oct 23 06:08:03 UTC 2014
> On Oct 22, 2014, at 8:40 PM, Alfred Perlstein <bright at mu.org> wrote:
>
>> launchctl(1) does all the XML parsing and then passes the results to launchd using its own custom IPC format. Was there some particular reason you violently inserted the XML parsing directly into launchd after the original architect(s) went to such pains to avoid such blatant penitentiary experiences? :-)
>>
> I could see the utility of that. One of our senior full stack devs says that XML is "triggering" and that they wouldn't want to work on such a system. Perhaps it's to keep web people out?
Well, whatever the rationale the pfsense-forkers (that sounds dirty) might have had, I think it’s fair to say that this is an abstraction layer that would be easy to add back since it exists that way in the original source code base, and I would certainly be happy to see it done (it could be done via a socket and a -h <hostname> argument added to launchctl if “something other than Mach ports” was the desired IPC mechanism and you even wanted to be able to drive a remote launchd through its paces). Either way, it’s the launchctl(1) command that ought to speak XML or YAML or any other reasonably structured format people like. Not embedding it in launchd is good for a lot more than architectural cleanliness.
As far as Mach IPC is concerned, it’s so prevalent in OS X and iOS largely because:
A) It’s already there.
B) The Mach port space confers certain security advantages (port rights, bootstrap sets, security trailers on all IPC).
C) It’s easy to create interfaces for it (MiG isn’t pretty, but it’s more than you get with sockets).
However, given that launchd starts up as pid 1 and can bind to a suitably secure low-numbered port for IPC (making it correspondingly harder to spoof launchctl) I don’t really see any reason, other than code compatibility, not to use another IPC mechanism in FreeBSD. I’d kind of like Mach ports in FreeBSD just to remove this final barrier to compatibility for a wide range of software that would otherwise cross the divide, but I also get that they’re a bit retro.
- Jordan
More information about the freebsd-hackers
mailing list