site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Oct 31, 2006, at 2:08 AM, Quinn wrote: -- Terry _______________________________________________ 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... 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. For the most part, the interesting thing is the blocking context, which is the kernel thread, rather than the proc (see bsd/kern/ kern_synch.c). Other than using the proc data for informational purposes (e.g. for displaying debugging information, such as the name or pid of a process that's calling your code), the proc is generally not as useful as you might think. Some parts can only be safely accessed under the proc_lock, proc_fdlock, or the kernel funnel (like everything to do with signals, creation, and deletion), or by taking a reference on it (which you'd need to later drop), so you need to be careful when referencing its contents to avoid it exiting out from under you. If *that* happens, you are a pointer dereference away from a kernel panic. This email sent to site_archiver@lists.apple.com