site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com <http://en.wikipedia.org/wiki/Unix_philosophy> kextload -b com.mycompany.driver.TabletDriver <http://developer.apple.com/qa/qa2001/qa1319.html> -- Terry _______________________________________________ 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... On Aug 11, 2009, at 12:17 PM, Eli Bach wrote: On Aug 11, 2009, at 11:40 AM, Tim Murison wrote: What is the reason why you don't want to use kextload? I generally prefer not invoking a utility from within my own program unless I have to. It strikes me as an ugly way of performing a task. If there is no other way then I'll invoke kextload, I was just hoping for an overlooked API. As far as I know, invoking kextload is the way to go. And of course, you'll need to invoke it with root-level privileges. I also recommend Mike Gancarz excellent book "The UNIX Philosopy". Here a the related Wikipedia article: In general, it recommends building larger tools out of combinations of smaller tools which do one thing, and do it well. While the underlying API used by kextload may change from release to release, or even as a result of a Software Update, the minimum set of options usually doesn't change as often; for example, the following command has been documented since 2002: That's true even though the underlying infrastructure has changed significantly over time. That said, you should most likely be using matching rules for you KEXT, if at all possible, and let it be loaded automatically by kextd, as needed. See also: For non-IOKit based KEXTs, your only options are likely to load your KEXT at boot time, or to specifically invoke kextload as a subprocess. See also the manual page for the popen(3) library routine. This email sent to site_archiver@lists.apple.com