site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com In that case I would just write it to a file (-: S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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 1:30 -0600 20/11/07, Kynan Shook wrote: So, what is a good way to get the data out of the kernel? I'm looking for fast and simple here - it's only a project, and will only ever be used on my machine, so minimizing the time spent on implementation is the priority. It's not that you /can't/ read or write files from the kernel, it's that doing this exposes you to all sorts of crazy deadlock situations. In this case, you're sitting at the block driver level and you end up calling all the way back up to the VFS level. It's very easy to deadlock due to reentrancy. It's also easy to deadlock due to lack of resources. OTOH, for a research project you should be able to make it work. You can get the vnode for a path using vnode_lookup. You can open it using vnode_open. And you can write to it using VNOP_WRITE. You don't even have to take a dependency on the kernel; these are all KPIs. You'd better make sure that the file you're writing to is on a different file system that the one that you're filter is running under (-: Keep in mind that the only reason I suggest this approach is that you're working on a research project. For production code I'd recommend a completely different approach. To come up with a good approach I'd have to ask you a bunch of questions about your constraints (like, for example, whether you care about dropping data, and the sort of performance characteristics you're looking for). However, for a research project you might as well take the shortcut. This email sent to site_archiver@lists.apple.com