site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 3, 2008, at 10:51 PM, nicolas vide wrote: Actually it means they will be more stable over the long-term. -Mike _______________________________________________ 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... On Sat, Oct 4, 2008 at 1:52 AM, Quinn <eskimo1@apple.com> wrote: Specifically, if you link against the entire kernel Just to be sure, when you say link against the kernel, that means building a new kernel with my IOService built-in? No, it means specifying in your kext's property list (Info.plist) in Xcode that you want access to interfaces outside of the KPI. But doing that means your KEXT is bound to a specific kernel version and even minor updates may prevent it from loading. See: <http://developer.apple.com/documentation/Darwin/Conceptual/KEXTConcept/KEXTC...

I don't know if it is right but I have the feeling that Apple tries to prevent as much as possible kext's accesses to the kernel functions & data. I am neither a driver person nor a kernel programmer but I played a little with Windows and FreeBSD and I could directly access to processes data structures for example: It is ease to hide a process just by modifying kernel data from a dynamic loadable driver. Obviously, this is a big advantage to prevent anyone to play with kernel internals data, however it means that third party software like anti virus software or monitoring tools will suffer of performance and security issues, right ? In a sense, yes, Apple (not that I can speak for them in any way) does want to limit 3rd part access to parts of the kernel. But the advantage to doing so is not as you've stated above. The reason they want to do that is the same reason any API exists: having a defined interface (for data and functions and for the semantics of using them) means the underlying implementation can change to support new hardware or to improve performance while not breaking existing code. If the entire content of the kernel is exposed and used equally by third parties it becomes almost impossible to change or improve anything because someone somewhere will have relied directly on the old architecture. Apple's KPI is what they intend to support long-term. Developers that stick to it will have less headaches from one release to the next than those who access everything directly. If you have a need for some interface that is not part of the KPI Apple would like to know about it. They aren't unreasonable. It's just they want to be able to improve the kernel over time and having every internal detail exposed equally as an interface we should use undermines their ability to do so. I've worked on Mac OS X and Linux drivers and I personally view Linus's adamant disdain for having a KPI in Linux as nothing more than laziness. It's easier for them but it causes me extra work every month to keep my code current. I have drivers under Darwin that have worked since 10.3 and still work today. I've not had a similar experience with Linux. This email sent to site_archiver@lists.apple.com