site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com HI Rodney, Thanks for the initial response. -- 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... On Aug 23, 2007, at 1:27 AM, JanakiRam wrote: I'm using the printf function defined at kernel. Is there any similar way for printf ( similar to IOLog). Can i use the IOLog in Generic Kernel Extension ? Rodney's answer is more or less correct; the standard kernel console log operations are written to a ring buffer which is serviced by syslogd, and there's nothing their to ensure that they are synchronous; it's expected that if you are debugging that type of problem, you would set ncpu=1 in the boot-args, and it wouldn't ever be an issue. By using the IOLog facility, you get locked access (but this doesn't stop anyone else from using printf and stomping in the middle of your IOLog). Either way, it gets into the same ring buffer, and you get to hope that syslogd in user space gets enough time to run to log the data reliably to a user space log file. The reason this facility isn't reliable is because (1) we didn't want kernel logging to be very verybose, (2) we didn't want people using it rather than the standard IPC mechanism, and (3) it's unacceptable to have a user space process (syslogd) potentially hang the kernel. Basically, if you want reliable communication from the kernel to user space, don't use logging, use one of the IPC facilities (sockets, IOKitUser, etc.) instead. If this is for debugging, and it's critical you don't lose data, then use the firewire debugging KEXT instead. This email sent to site_archiver@lists.apple.com