Mac OS X Internals: A Systems Approach
All
Stack Overflow 7
This Year
Stack Overflow 2
This Month
Stack Overflow 2
https://www.amazon.com/gp/product/0321278542/
I believe the book the OP is referring to in their post is effectively newer editions of Amit's book, but I could be wrong.
This is actually a bit more complicated. The kernel is composed of two parts, BSD and the mach kernel; the latter being responsible for management of memory and process scheduling.
Each mach process has one or more mach tasks (really task port rights!). When an application is first launched, it has just one right, the bootstrap port, allowing communication with launchd. Note that a task port right is uni-directional, so a launching process that has the right to communicate with launchd must give a right for launchd to communicate back to it.
When an XPC message is received by launchd, it depends upon the Launch Daemon as to what action it takes. It's possible that the message is for a service that runs with a network port that may or may not be running. If running, it forwards any arguments from the calling process to the running service. If not running, it can provide the service on demand by launching the process first.
More specifically you asked about
launchctl load. Since the source code for launchd is no longer open source, the next best resource is the reverse engineering work by Jonathan Levin; Author of Mac OS X and iOS Internals and more recently, his newer self-published books on *OS Internals.You'll find his slides about launchd here, but probably more useful to you is his version of launchctl, jlaunchctl which is open source.
Finally, if you want to view content of XPC messages between processes, disable SIP and use Jonathan's invaluable XPoCe tool.
I don't believe there's any high level API that allows you to do this.
However, as you state you're familiar with Kernel development, that's the way to go and indeed it's how the parental controls work; with a kernel extension (kext).
This article explains about 4 scopes of interest for authorization in the kernel. You'll need to write a kernel extension and monitor the VNode scope, which will inform your kext of all vnode access by calling a function defined in your kext. This function must then return one of either Accept, Deny or Defer. If you call Deny on access to a vNode that is making an Execute operation, then it will be blocked.
Finally, if you're going to write any kernel code, then I recommend you get a copy of this book, which includes example code based around monitoring the vnode scope.
As mentioned in Mac OS X Internals: A Systems Approach and Qt Mac (Re)move "Special Characters..." action in Edit menu, you can do something like this in main() before you load the nib (but it is not supported API):
If your device is basically just a serial device plugged into a standard USB/serial adapter, you shouldn't need to drop to the IOKit level. Locate the UNIX character device for your serial port and open that for unbuffered file I/O. You may want to traverse the I/O kit registry purely for enumerating ports, but you shouldn't need it for actual I/O.
To get you started with that, you'll want to create a matching dictionary with:
and then get the returned devices' file paths via the
kIOCalloutDeviceKeyproperty.If it's not a standard USB/serial adapter, you'll need to use IOKit. I unfortunately don't know any better web resources than Apple's on the topic of USB and drivers, but there are books:
OS X and iOS Kernel Programming is specifically targeted at (aspiring) driver programmers. It contains 2 chapters on USB, one for USB fundamentals and kernel space drivers, and one on user-space USB drivers. You should hopefully be able to get up and running with those. (Disclaimer: I was one of the tech reviewers for this book; I don't get paid to advertise it, however, and I don't get royalties)
Mac OS X Internals is starting to show its age (it's current as of OS X 10.4) and isn't specifically a driver development book. It does give very detailed descriptions of many parts of OS X and its kernel though. Not an awful lot on USB, if I remember correctly.
For USB, you have 2 options: user space and kenel space drivers. Unless you have a good reason to do it in the kernel, I suggest doing it in user space. The APIs are very different, the kernel API is C++, userspace is C. (no, I didn't mix those up) when looking at documentation, make sure you're looking at the right one of the 2 - they're both called I/O Kit!
There isn't a Cocoa API for the motion sensor. It's only available through calls to IOKit. It's described in Mac OS X Internals.
Basically, this guy is right.
Go download the source code that accompanies this book and see vm_rw_master.c of example 8-16 for a working implementation.
See http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/ for documentation, it's slightly outdated, and questionably correct, but it's the best available.
EDIT: Also, see http://lightbulbone.com/2011/05/dumping-process-memory-on-mac-os-x/ (note that the task who owns memory you are trying to read does NOT need to be a child of the process trying to do the reading, you just need to have the proper authorization.)
EDIT: Also, see http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/ for a good example of authorization.