site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? Sounds convoluted, but it still could be an option. ~ Josh On Dec 26, 2006, at 1:38 PM, Curtis Jones wrote: Albeit somewhat brute-force, Jonathan Rentzsch's mach_override can solve a lot of tough problems. With some adaption, you could use it to override the kernel's pset_add_task(processor_set_t pset, task_t task) or similar function with your own version. In this case you would simply get the needed information out of the task_t before calling the real pset_add_task. That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? -- Curtis Jones _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... When you override, you are copying your custom function into the kernel's permanent memory. Your custom function will *not* be erased along with your kext (during unload). You would have to have a status bit in memory that indicates whether or not your kext is loaded, so that your override function would know whether or not it should perform the custom operations. On 12/26/06, Josh Rodatus <josh@rodatus.com> wrote: Since mach_override would need adaption for use within the kernel, and it's also processor-dependent, you could write your own special-purpose overriding routine based on the same principles. This email sent to site_archiver@lists.apple.com
participants (1)
-
Josh Rodatus