Re: printf logs are not getting printed properly on system.log
Re: printf logs are not getting printed properly on system.log
- Subject: Re: printf logs are not getting printed properly on system.log
- From: Terry Lambert <email@hidden>
- Date: Sat, 25 Aug 2007 04:07:49 -0700
On Aug 23, 2007, at 1:27 AM, JanakiRam wrote:
HI Rodney,
Thanks for the initial response.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden