On Thursday, January 30, 2003, at 05:42 PM, Marek Kozubal wrote: I think this will do what you want. http://www.java-internals.com/code/mig_in_kernel.html Its a sample project on how to call MIG (Mach Interface Generator) functions from a kext. It passes the mach port in via sysctl, however you can also do it other ways (like one of your private args to the mount structure you pass mount()). I won't even mention what I think of its syscall-patching mechanism (except to say that it deserves to break at every opportunity). More specifically on this point, it makes a few incorrect assumptions about how the Darwin kernel works. First off: There really are two modes within the kernel. There is the kernel task mode - which is pretty much a full-blown Mach task for kernel-resident threads to execute within. Then there is the kernel's system/library executive mode - in which threads executes when they trap into the kernel from other task contexts. Not all kernel services work in both modes (many assume all callers are running in one mode or the other), and some services simply behave differently when called while running in the two modes. Mach IPC is one of those things that behaves quite differently, depending upon your kernel mode. When you are running in the trap mode, Mach assumes you are intimate with the implementation of Mach IPC (and may actually be assisting in its implementation). So lots of validity checking is bypassed. Port rights are held in limbo and not inserted into the kernel task's port name space (these are known as "naked" rights in the code comments) because Mach IPC assumes they are just on their way out to another task. Likewise, out-of-line memory regions are not mapped into the kernel's address space, but kept in vm_map_copy_t shorthand notation for later mapping into the true receiver task. Heck, even the Mach message headers are not converted into local perspective (local and remote ports swapped) because the message is just assumed to be "in-flight." Because of these distinctions, there are different IPC primitives available (send-from-kernel, rpc-from-kernel, but no "receive-from-kernel" because you aren't really a kernel thread at that point). Hooking up to receive trap-mode Mach IPC is even more difficult. MIG can compensate for some of these differences if you tell it you are running in the trap mode. But you have to deal with many of the differences manually (you ARE a kernel programmer after all...). In the example referenced here, they call mach_port_extract_right() from within trap mode. That routine expects to be running in that mode (which is good), but it expects to be doing its work on behalf of a user task, not the kernel. Specifically, the extracted port right is returned as a naked right - the caller is assumed to be a MIG-generated server-side stub which will pack it into a (trap mode) message and send that back out to user space. The port right is NOT inserted into the kernel ipc_space (port name space). All the calls trying to manipulate the kernel ipc_space are at best ineffective - leaking the naked port rights, and therefore the associated memory (~100000 exits and this thing will likely panic). Even worse, they are potentially more dangerous - by accidentally deallocating a right that really was inserted into the kernel's port name space by a kernel-bound thread (and causing it to misbehave in less obvious ways). See. None of this is easy. Is it? Programming unassisted in the kernel is not for mere mortals. That's why IOKit provides its own wrapper to all this that makes requesting and sending notifications, both to your own user-clients and to people listening on registry changes, relatively painless by comparison. As we develop facilities to support binary compatible extensions for other KEXT models (like FS, and NKEs), we will be providing notification mechanisms that match those models as well (with APIs that feel and behave natively to those programming environments and yet are catchable in other environments). This just takes quite a bit of time and effort to do right. But without it, we don't feel like we have a complete story and didn't want to have people trying the things that will clearly get them in trouble (like above). --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.