From tyler at bleepsoft.com Sun Sep 24 14:51:40 2006 From: tyler at bleepsoft.com (R. Tyler Ballance) Date: Sun Sep 24 14:53:25 2006 Subject: [launchd-dev] Re: [launchd-changes] [22881] trunk/launchd/src In-Reply-To: <20060924213817.61615155012@cvs.opensource.apple.com> References: <20060924213817.61615155012@cvs.opensource.apple.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought the Mach goo was starting to be separated out into its own gooey file? :) You mention it being more work to keep the artificial division, but I though the "division" was one of the goals of making launchd "more" open source? To allow for (namely me :P) the community to start adapting launchd to other non-Mach (and thus no wonderful MIG) systems, like FreeBSD. From my understanding _unix_ipc.c and _mach_ipc.c weren't too "relevant" in terms of offering different IPC implementations, but I was under the impression that further down the line I would be throwing pure unix sockets (or otherwise) IPC into the former for FreeBSD/OpenBSD/etc while the majority of launchd IPC on Darwin remained tied to Mach ports? Besides, its a Sunday, tsk tsk, working on a sunday ;) Cheers, - -R. Tyler Ballance Lead Developer, bleep. LLC http://www.bleepsoft.com On Sep 24, 2006, at 4:38 PM, source_changes@macosforge.org wrote: > Revision 22881 Author zarzycki@apple.com Date 2006-09-24 14:38:16 > -0700 (Sun, 24 Sep 2006) Log MessageFold launchd_mach_ipc.c into > launchd_core_logic.c. This isn't as bad as it sounds. MIG does > nearly all of the hard Mach related IPC logic. It was actually more > work in the long run to keep the artificial division. For the > casual reader, the code that is in launchd_unix_ipc.c is > automatically generated from MIG via the ".defs" file. I was > surprised to see that launchd_mach_ipc.c was empty after the MIG > callouts were folded into launchd_core_logic.c. In hindsight, that > made sense. The rest of the Mach goo was folded into launchd_runtime.c -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFFv3uqO6nEJfroRsRAr/yAJsEETa07LPUprxZcPf9BYpH6WFHEgCggx29 6yadHZFY7KDL9Tu9m/qLOwo= =m5Ah -----END PGP SIGNATURE----- From zarzycki at apple.com Mon Sep 25 09:42:39 2006 From: zarzycki at apple.com (Dave Zarzycki) Date: Mon Sep 25 09:44:10 2006 Subject: [launchd-dev] Re: [launchd-changes] [22881] trunk/launchd/src In-Reply-To: References: <20060924213817.61615155012@cvs.opensource.apple.com> Message-ID: On Sep 24, 2006, at 2:51 PM, R. Tyler Ballance wrote: > I thought the Mach goo was starting to be separated out into its own > gooey file? :) > > You mention it being more work to keep the artificial division, but > I though the "division" was one of the goals of making launchd > "more" open source? To allow for (namely me :P) the community to > start adapting launchd to other non-Mach (and thus no wonderful MIG) > systems, like FreeBSD. From my understanding _unix_ipc.c and > _mach_ipc.c weren't too "relevant" in terms of offering different > IPC implementations, but I was under the impression that further > down the line I would be throwing pure unix sockets (or otherwise) > IPC into the former for FreeBSD/OpenBSD/etc while the majority of > launchd IPC on Darwin remained tied to Mach ports? Hmm? I'm trying to keep the layering within the launchd project as clean as possible. Really, I am. :-P What that means is that I'm not going to gratuitously use the wrong technology for dogmatic reasons. Sometimes Mach provides a better API/ tool. Sometimes Unix does. I don't wish to preclude porting, but I've got a job to do too. This is one of the reasons why launchd tries to keep itself at the system-call boundary as much as possible. I'm going to try and keep the Unix IPC alive, but you may find some of it disabled in the future with C-preprocess macros. I'll need you or someone else in the community to test/use it and keep that code functional. :-( Like I said, I've got a job to do. I'm happy to work with you at integrating any code that makes launchd portable. Cheers, davez