Re: Getting the current PID inside kext?
Re: Getting the current PID inside kext?
- Subject: Re: Getting the current PID inside kext?
- From: Quinn <email@hidden>
- Date: Tue, 31 Oct 2006 10:08:16 +0000
At 21:19 -0800 30/10/06, Rick Mann wrote:
This document seems to indicate that sys is available, but when I
include <sys/proc.h>, struct extern_proc does not get declared. I
can't seem to figure out why not, except perhaps the compiler is
including a different file than Command-D is opening up for me.
Indeed. There are *three* versions of each of the kernel-level headers:
1. There's the original version in the kernel source code. You can
get this from Darwin. This is the version from which the others are
derived.
2. There's a user space version in "/usr/include". This has all of
the kernel-only stuff preprocessed out.
3. There's a version for third party kernel development in the Kernel
framework ("/System/Library/Frameworks/Kernel.framework/Headers").
This has all of the user space stuff preprocessed out.
Both 2 and 3 also have all of the implementation details preprocessed
out. So, for example, within the kernel we want you to treat the
process object as opaque, and thus the <sys/proc.h> in the Kernel
framework doesn't have the definition for (struct proc) [1].
The key point here is that, if you're writing code that you want to
be binary compatible with future systems, you should only use
declarations from 2 or 3 (for user space and kernel code,
respectively). These are the things that Apple considers to be
API/KPI.
When you create a KEXT project in Xcode, Xcode passes magic options
to GCC to disable the automatic search of "/usr/include" and to
instead search the Kernel framework.
* * *
And yes, Xcode does have a habit of showing you the wrong file when
you use Open Quickly. When doing kernel development, I generally add
the Kernel framework to my project, disclose the header list, and
type select the relevant header.
* * *
And back to your original question...
At 21:00 -0800 30/10/06, Rick Mann wrote:
Can I use <sys/proc.h> and extern_proc with current_proc() to get at the pid?
You can use a variety of different routines from <sys/proc.h> in the
Kernel framework. For example proc_selfpid() or
proc_pid(proc_self()).
I should caution you that there are circumstances when this won't
yield the results you're expecting. For example [2], if you did this
on the read/write path of an asynchronous I/O, you might find that
proc_self() isn't the process that originally issued the I/O (it's
the process that happened to be around when the I/O started). That's
the reason why the VFS KPI has a separate vfs_context_t parameter,
from which you can derive the original process.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
[1] This is a simplification. In fact, most of the truly internal
stuff has moved to a parallel header. So (struct proc) is actually
defined in <sys/proc_internal.h>.
[2] With apologies to the /real/ kernel engineers on the list, who
know how this stuff actually works. I'm trying to make a pedagogic
point here (-:
_______________________________________________
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