Re: Register a task's exception port from a kext
Re: Register a task's exception port from a kext
- Subject: Re: Register a task's exception port from a kext
- From: Michael Cashwell <email@hidden>
- Date: Sat, 4 Oct 2008 19:02:24 -0400
On Oct 3, 2008, at 10:51 PM, nicolas vide wrote:
On Sat, Oct 4, 2008 at 1:52 AM, Quinn <email@hidden> 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/KEXTConceptDependencies/kext_dependencies.html
>
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 ?
Actually it means they will be more stable over the long-term.
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.
-Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden