Re: Mach Bootstrap_create_server, "server_command" parameter
Re: Mach Bootstrap_create_server, "server_command" parameter
- Subject: Re: Mach Bootstrap_create_server, "server_command" parameter
- From: Quinn <email@hidden>
- Date: Tue, 17 Feb 2009 14:10:52 +0000
At 5:50 -0500 17/2/09, Michael Prenez-Isbell wrote:
Not sure what I think about actually eliminating an API in favor of a config
oriented approach. Why not just document the API properly. Nothing wrong
with the API and it seems to me it's more coherent with the rest of the Mach
API. Just my two cents.
This stuff makes a lot more sense once you grok the launchd
philosophy. Specifically, launchd is all about launching on demand.
That is, rather than some master script controlling how the system
boots (/etc/rc, or its logically successors), launchd launches
services on demand. It starts one master service (loginwindow) and
then, as that service requests other services, it launches those
services, and so on. This has a number of advantages:
o system boot is lazy--only services that need to start get started
o startup is inherently parallel
o there's no need to maintain a master startup script
However, for this to work launchd needs to know which services exist
and how they get launched on demand. And that's what the
configuration files are all about.
Just out of curiosity, is there some historical reason why there is so
little real example code out there on the web for the mach stuff.
It's not just a historical reason. In general Apple recommends that
developers avoid using Mach APIs directly if they can. This is
because the Mach APIs are the lowest-level interface to the kernel,
so they are more likely to be affected by changes to the underlying
kernel. Also, the behaviour of the Mach APIs is not standardised,
which makes it harder for us to do the right thing binary
compatibility-wise.
To encourage folks to avoid Mach, we don't document them well, and we
don't ship formal sample code for them, except in situations where a
Mach API is the only good solution to a particular problem.
It's also important to realise that we don't have enough resources to
document all the APIs that we actively /want/ developers to use (VFS
KPI documentation, I'm looking at you!). So the fact that the Mach
APIs are not properly documented isn't saying too much (-:
Just to be clear, the Mach APIs are /supported/. We ship the headers
as part of the public SDK, DTS answers questions about them, and
kernel engineering does its best to avoid breaking them. However, if
there is a good alternative, I'd recommend that you use it. [Insert
Quinn's standard plug for UNIX domain sockets (-: ]
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden