site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dave Zarzycki writes:
On Jun 2, 2006, at 12:14 PM, Andrew Gallatin wrote:
Let's take my software as a concrete example.
I maintain my company's HPC drivers and software on MacOSX. We have a start/stop script which we plug into the rc.d/init.d/blah startup scripts on the other *nixes we support, and which is warped into a startup item on MacOSX. This script basically does 2 things
1) Loads the driver for the cluster interconnect
I thought IOKit's matching system does this automatically for you? Does it not?
Only if its installed in S/L/E, and then no symbol information is provided to debug possible problems. Then there is the involvment with the kextcache. For a driver that does not need to be loaded at startup, it is much nicer to load it from a startup script.
2) Starts a fabric mapper which runs over the interconnect.
My requirements are simple. I want to be called last, after networking and disks and all that stuff is available.
What if they're not available at boot? What if they come online later?
I should have said "root volume" I suppose. For servers with the PCI-X and PCI-e slots to accept our producs, your "not available at boot" doesn't happen. Or if it does, the server is sick and has bigger problems than our stuff not starting.
I want the hostname to be more-or-less stable...
That's out of Apple's control. You'll have to talk to your sysadmin if you want that.
Most admins of 1000 node clusters don't change the hostnames willy-nilly, so this isn't a problem. I just need to be run after the first real hostname is set. That's a pretty simple requirement that is easy to express in other, less shiny, startup paradigms ('REQUIRE: hostname' in BSD).
How does this fit into the launchd model?
Depends on how robust you want to make the daemon.
The easiest, but least robust thing to do is to use IOKitWaitQuiet() at the beginning of your main(). If your driver isn't loaded after that call returns, then take the lazy way out and call abort(). After that point, you'll need to use one of the SystemConfiguration framework APIs to do the moral equivalent of IOKitWaitQuiet() except for networking. I'm not an expert at that framework, otherwise I'd mention what API you need to use. After that, you're good to go just like you used to.
If you wish to make your daemon robust, you'll register for callbacks for when your hardware shows up and probably more importantly, to monitor for network configuration changes and adjust the fabric as required.
I'm sorry, but that sounds way to Apple specific to bother with. We use as little of IOKit as possible, and the daemon uses BSD ioctls to communicate with the driver. This allows the vast majority (99% of the daemon, 80% of the driver) to be shared between Linux/*BSD/Solaris/MacOSX/Windows. The daemon knows nothing about MacOSX, and just makes MI ioctls to our driver. All I want is for you not to remove the nice, simple, non-Apple specific way to start things that you currently have with startup items. Thanks, Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com