Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: Andrew Gallatin <email@hidden>
- Date: Fri, 2 Jun 2006 16:50:18 -0400 (EDT)
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden