Using launchd to load and configure a kernel extension in OS X

I am writing a network kernel extension for socket filtering. To make it configurable, a userland program reads a config file and passes the information to the kext through a PF_SYSTEM socket.

If I want to have the socket filter up and running as soon as possible at system startup, how would I choreograph the launch?

My current idea is to use launchd to start a small userland initializer program. This program would use kextload to start the kext. After that, it would read the config file and talk to the kext through the PF_SYSTEM socket. Having done its job, it would then quickly exit.

Another option would be to have two launchd items, one for the kext (using kextload) and another for the userland configuration file reader. This would avoid the fork, but would otherwise be identical. Either way, launchd would have to run a quick non-daemon userland program.

However, launchd seems to be geared towards launching actual daemons, not for quick tasks that do their work and exit. The developer library document says:

Important: If your daemon shuts down too quickly after being launched, launchd may think it has crashed. Daemons that continue this behavior may be suspended and not launched again when future requests ar开发者_如何学Pythonrive. To avoid this behavior, do not shut down for at least 10 seconds after launch.

This gives me the impression that launchd is not the correct way to do this. How should I organize the launch? Is my whole idea going in the wrong direction?

(As a side note, I want to give the user the possibility to alter the filtering options during runtime too. I imagine this can be done simply by opening a new PF_SYSTEM socket connection to the kext whenever changes are needed.)

I think that caveat only applies to daemons that are launched on demand.