November 2006 - Darwin-kernel

SIGTHR missing?
by Joseph Oreste Bruni 30 Nov '06

30 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, In the man page for signal(3), there is a list of valid signal numbers, one of which is called SIGTHR: 32 SIGTHR terminate process thread interrupt However, this signal is not listed in sys/signal.h. Is this signal implemented in the kernel? If not are there plans to? Joe -- PGP Fingerprint: C54A C9DD 84AD C6FC D343 67C4 5195 D63A CD55 18C7 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel log: app uses send/recv on a pipe
by Tomasz Kukielka 30 Nov '06

30 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AccUKc0QC9Dh/4AdEduB6wAX8i08Wg== Thread-topic: Kernel log: app uses send/recv on a pipe User-agent: Microsoft-Entourage/11.2.5.060620 Thanks a bunch for this tip! Ironically, this was my original implementation but then I thought that the kCFSocketDataCallBack is more elegant because I get a ready CFDataRef while kCFSocketReadCallBack required reading unknown amount of data (and I was afraid that I may block in read call if no data available). I did not notice that the kernel warning happened only after I switched to CFDataRef. This solves my problem. On a related note I wish it was possible to to create CFReadStream directly from file descriptor or FILE * stream (Cocoa NSFileHandle can initWithFileDescriptor) Thanks, Tom On 11/29/06 2:31 PM, "Quinn" <eskimo1(a)apple.com> wrote: > At 10:39 -0800 29/11/06, Vincent Lubet wrote: >> The alternative is to use socketpair(2) > > Or tell CFSocket /not/ to read the data for you (use > kCFSocketReadCallBack instead of kCFSocketDataCallBack), in which > case it will only notify you when data is available and leave you to > read the actual data. Your callback can then read the data using > <x-man-page://2/read> and avoid the message. > > S+E _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel log: app uses send/recv on a pipe
by Quinn 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 10:39 -0800 29/11/06, Vincent Lubet wrote: The alternative is to use socketpair(2) Or tell CFSocket /not/ to read the data for you (use kCFSocketReadCallBack instead of kCFSocketDataCallBack), in which case it will only notify you when data is available and leave you to read the actual data. Your callback can then read the data using <x-man-page://2/read> and avoid the message. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kdebug_chudhook: need finer grained kdebug
by Terry Lambert 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 29, 2006, at 1:36 AM, Robert Kueffner wrote: Hi, the kdebug trace facility provides kernel event logs via typedef struct { uint64_t timestamp; unsigned int arg1; unsigned int arg2; unsigned int arg3; unsigned int arg4; unsigned int arg5; /* will hold current thread */ unsigned int debugid; } kd_buf; The short answer is "don't do this". The next shortest answer is "why do you want to do this?". After that, the answers get longer. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Logs sampled over some time interval are retrieved by existing commands (sc_usage, latency etc) and a program described in Singh's OSX internals, Fig 6-39. The value of the debugid-field denotes the invocated function, corresponding names given in /usr/share/misc/ trace.codes MY PROBLEM 1) I need to extract the particular parameters and returned values, say in the case of MACH calls. 2) I need to perform actions immediately after starting/before finishing an operation, instead of just processing logs I found that (mig generated) messages requesting (as well as replying to) the operations are also traced. arg1 & arg3 give the message address in memory and its size. At the time logs are retrieved the contents of these messages is most likely lost, though, so parameters etc are not available. SOLUTION? A solution could be to register a kdebug_chudhook() callback to retrieve the logs including the messages during their transmission. As far as I understood, CHUD itself does not seem to export this. (although chudMaxKDebugTraceSampleLimitCallback() sounds related, an undocumented funtion from chudKDebugTrace.h) Does anybody know how to register a kdebug_chudhook() callback? (I am aware this would be a kernel context callback that must not be messed up) Is there a more straightforward solution? Any help is greatly appreciated! In general, you cannot trap kernel entries or exits, and even if you were able to do so by abusing this monitoring trace record cutting mechanism, it only applies to processes that are currently being ktrace'ed, and then it's only a notification mechanism. In other words, whatever actions you perform will have to be non-destructive - not change any of the arguments into, or any of the results out of, a given system call or Mach call. Technically, it's possible to abuse this with knowledge of the specific call graph and assembly code involved, to get at the spill area and register spills from function calls in progress on the stack, and hack around arguments (if I can do it, I'm sure someone else can figure out how to do it, after all), but there's no guarantee that this type of hack would not break on each and every software update, so it's not like you could use this approach to make a useful product that would not need continuous ongoing maintenance and probably result in a lot of bug reports to Apple that aren't Apple's fault. So now we are back to the next shortest answer of "why do you want to do this?". It's likely that, if you tell us the problem you are trying to solve - i.e. something less generic than "I want to hook all the system calls for some unspecified and probably nefarious reason" - then we can probably give you a couple of better approaches to solve the actual problem you want solved, without doing anything that makes you dependent on implementation details we won't promise not to change, or likely to break you or someone else down the road. This email sent to site_archiver(a)lists.apple.com

1 0

Re: waiting queue
by Michael Smith 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Hello Michael, Maybe to clarify what I ultimately want: * When the interrupt has occurred, the driver returns. client_call() { while (flag == 0) { } flag = 0 } interrupt() { flag = 1 } client_call() { if (flag == 0) // XXX race window sleep(&flag) flag = 0 } interrupt() { flag = 1 wakeup(&flag) } client_call() { mutex_lock(mtx) if (flag == 0) mutex_sleep(&flag, mtx) flag = 0 mutex_unlock(mtx) } interrupt() { mutex_lock(mtx) flag = 1 wakeup(&flag) mutex_unlock(mtx) } class foo : public IOService { ... public: IOReturn clientCommand(..); private: IOWorkLoop *_workLoop; IOCommandGate *_commandGate; IOCommandGate::Action _commandAction; IOInterruptEventSource *_interruptSource; bool _busyFlag; bool _interruptOccurred; ... }; foo::start(IOService *provider) { ... _workLoop = IOWorkLoop::workLoop(); foo::_clientCommand(...) { // wait for other callers to depart while (_busyFlag) _commandGate->commandSleep(&busyFlag, THREAD_UNINT); _busyFlag = true; // wait for interrupt event while (!_interruptOccurred /* XXX && !_timedOut */) { _commandGate->commandSleep(&_interruptOccurred); // XXX check for timeout here too } // process interrupt results _interruptOccurred = false; ... // unlock and return _busyFlag = false; _commandGate->commandWakeup(&busyFlag, true /* wakeup one only */); } foo::_interruptHandler(...) { // quiesce the hardware interrupt foo::_timeoutHandler(...) { _timedOut = true; _commandGate->commandWakeup(&_interruptOccurred); } Hopefully this helps... = Mike On 16.11.2006, at 19:12, Michael Smith wrote: class foo : public IOService { ... public: IOReturn clientCommand(..); private: IOCommandGate *_commandGate; IOCommandGate::Action _commandAction; IOReturn _clientCommand(...); bool _busyFlag; ... }; foo::clientCommand(...) { _commandGate->runAction(_commandAction, ...) } foo::_clientCommand(...) { while (_busyFlag) _commandGate->commandSleep(&busyFlag, THREAD_UNINT); ... _busyFlag = false; _commandGate->commandWakeup(&busyFlag, true /* wakeup one only */); } = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… devmaillists wrote: thank you very much. I tried to fully understand IOCommandgate / IOCommandPool / IOCommand / IOWorkloop but I got stuck in the Apple documentation. I used the darwin sources the get some knowledge but it didn´t explain the mechanism. Are there some source of documentation I could try in addition? If looking at the example I gave you, and how they are used in the Darwin sources doesn't help, then I'm not sure that any more documentation is going to help. * The driver gets calls (from a user space programm) that should wait for an event and return when this event has occurred (1) * The kernel driver, well, waits for this event -- is indicated by an interrupt -- to happen. I can trigger intterupts on the card, and handlers get called when they occur. But somehow I can not get my brain wrapped around IOCommandGate et. al. Perhaps working this from scratch will help. The most naive implementation of the above looks something like this: Now, this has the problem that the while loop spins and consumes 100% of the CPU. So instead you want to put the thread to sleep, and have the interrupt routine wake it up: But there is a race here between the if test and going to sleep. If the calling thread is pre-empted by the interrupt, the flag will be set and the wakeup issued, but it will be missed by client_call. So you need a mutex: So at this point, we've just about got it. There's only one catch left; mutex_lock() can block, and you don't ever want to block in interrupt context. I/O Kit handles this by providing two kinds of interrupt handler; the traditional interrupt-context handler routine referred to as an "interrupt filter", and the default interrupt handling routine. This separation is very similar to using a DPC under Windows or task_queues under Linux. The primitives that come in at this point are the WorkLoop, and the concept of event sources. The WorkLoop can be considered to be built from three things; all of them are managed by the implementation. They are: a mutex lock, a thread, and an event registration list. The event registration list provides a way for the thread to find things that need to be done under the lock. In this regard, it can be considered analagous to an allocatable task_queue in the Linux vernacular. To use this functionality, you register event sources with the WorkLoop; your ::start routine almost certainly allocates an IOInterruptEventSource and then attaches it to your WorkLoop, and this is how interrupts are delivered to you. So you can see how that covers the locking for the interrupt routine; your handler is implicitly called with the WorkLoop lock held, ensuring mutual exclusion with any other event source. In the trivial case, you may wonder why all this infrastructure, but when you start adding timers to your driver, or multiple interrupt sources, power management etc. you will quickly see how the IOEventSource model helps keep them all in line. However, incalls from clients aren't events, and in the name of performance you really don't want to schedule a new thread and take the context switch hit every time just to avoid being pre-empted by your interrupt handler. So you need a way to take the WorkLoop lock, and to sleep safely when you hold it. This is where the CommandGate comes in, and now we come back to my previous example with some additions to map to the description here. IOReturn _clientCommand(...); void _interruptHandler(IOInterruptSource *source, int count); _commandGate = IOCommandGate::(this); _workLoop->addEventSource(_commandGate); _commandAction = OSMemberFunctionCast(IOCommandGate::Action, this, &foo::_clientCommand); _interruptSource = IOInterruptEventSource::interruptEventSource(this, OSMemberFunctionCast(this, IOInterruptEventSource::Action, _interruptHandler), provider, 0); ... } foo::clientCommand(...) { _commandGate->runAction(_commandAction, ...) } _interruptOccurred = true; _commandGate->commandWakeup(&_interruptOccurred, true /* wakeup one only */); } 1) There may be a timeout, but let's not make things too complicated here For sure. However, if you want to consider the possibility, bear in mind that you'd just add an IOTimerEventSource and have its handler do something like this: devmaillists wrote: we are to implement waiting queues for scheduling threads generated from a UserClient interface in our kext. As I learned from the documentation I should use wait_queue_alloc , wait_queue_free, wait_queue_member and so on to implement wait queues. Unfortunately I do not find the symbols in the 10.4 SDK only in 10.39 SDK but I think this is not an option for Intel based developments. What is the preferred way to do wait queues with 10.4 SDK. If by "wait queues" you mean that you want to queue incoming threads, then you should use a CommandGate with your workloop. Something like this: foo::start() { ... _commandGate = IOCommandGate::(this); getWorkLoop()->addEventSource(_commandGate); _commandAction = OSMemberFunctionCast(IOCommandGate::Action, this, &foo::_clientCommand); _busyFlag = false; ... } The busy flag acts as the semaphore indicating that there's a thread in the critical region. The workloop lock is used to provide concurrency protection against your interrupt thread, and making it possible to sleep waiting for that thread without having to deal with other threads coming into the critical region. Caching the result of OSMemberFunctionCast is advisable, as it is somewhat expensive. This email sent to site_archiver(a)lists.apple.com

1 0

Re: waiting queue
by devmaillists 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello Michael, Maybe to clarify what I ultimately want: * When the interrupt has occurred, the driver returns. On 16.11.2006, at 19:12, Michael Smith wrote: class foo : public IOService { ... public: IOReturn clientCommand(..); private: IOCommandGate *_commandGate; IOCommandGate::Action _commandAction; IOReturn _clientCommand(...); bool _busyFlag; ... }; foo::clientCommand(...) { _commandGate->runAction(_commandAction, ...) } foo::_clientCommand(...) { while (_busyFlag) _commandGate->commandSleep(&busyFlag, THREAD_UNINT); ... _busyFlag = false; _commandGate->commandWakeup(&busyFlag, true /* wakeup one only */); } = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… thank you very much. I tried to fully understand IOCommandgate / IOCommandPool / IOCommand / IOWorkloop but I got stuck in the Apple documentation. I used the darwin sources the get some knowledge but it didn´t explain the mechanism. Are there some source of documentation I could try in addition? * The driver gets calls (from a user space programm) that should wait for an event and return when this event has occurred (1) * The kernel driver, well, waits for this event -- is indicated by an interrupt -- to happen. I can trigger intterupts on the card, and handlers get called when they occur. But somehow I can not get my brain wrapped around IOCommandGate et. al. 1) There may be a timeout, but let's not make things too complicated here devmaillists wrote: we are to implement waiting queues for scheduling threads generated from a UserClient interface in our kext. As I learned from the documentation I should use wait_queue_alloc , wait_queue_free, wait_queue_member and so on to implement wait queues. Unfortunately I do not find the symbols in the 10.4 SDK only in 10.39 SDK but I think this is not an option for Intel based developments. What is the preferred way to do wait queues with 10.4 SDK. If by "wait queues" you mean that you want to queue incoming threads, then you should use a CommandGate with your workloop. Something like this: foo::start() { ... _commandGate = IOCommandGate::(this); getWorkLoop()->addEventSource(_commandGate); _commandAction = OSMemberFunctionCast(IOCommandGate::Action, this, &foo::_clientCommand); _busyFlag = false; ... } The busy flag acts as the semaphore indicating that there's a thread in the critical region. The workloop lock is used to provide concurrency protection against your interrupt thread, and making it possible to sleep waiting for that thread without having to deal with other threads coming into the critical region. Caching the result of OSMemberFunctionCast is advisable, as it is somewhat expensive. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel log: app uses send/recv on a pipe
by Vincent Lubet 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com The alternative is to use socketpair(2) Vincent On Nov 29, 2006, at 9:35 AM, Tomasz Kukielka wrote: On 11/29/06 9:26 AM, "Vincent Lubet" <vlubet(a)apple.com> wrote: This message is there to alert developers they should not use sockets system calls like send() and recv() on pipes as pipes are no more backed by sockets since Tiger 10.4. You should use write() and read() instead. Vincent On Nov 28, 2006, at 10:38 PM, Tomasz Kukielka wrote: Hi, I noticed the following kernel message in system log: Nov 28 20:10:42 TK-MB kernel[0]: CommandDroplet[1993] uses send/ recv on a pipe CommandDroplet is the application that I develop as part of OnMyCommand which wraps Unix or AppleScript scripts with some GUI. I have been experimenting with it recently trying to make popen execution non- blocking. The problem is with pipe caching (you cannot work it around) which locks the reading and you get stuck in in fread (or fgets). I wanted to improve it but nothing seemed to work until I created a CFSocket on the file description from the stream. It works beautifully as a CFRunLoop source - providing a data in callback and not blocking. But the kernel message is a signal that there might be something wrong with it. See below for the code I used. When I #undef USE_CFSOCKET the kernel does not complain. I would really hate to go back to the previous synchronous/blocking code. Thanks, Tom http://www.abracode.com/free/cmworkshop/ bool POpenExecutor::Execute( const char *inCommand ) { if(inCommand == NULL) return true; FILE *fp = popen( inCommand, "r" ); if ( fp != NULL ) { #ifdef USE_CFSOCKET CFSocketContext context; context.version = 0; context.info = this; context.retain = NULL; context.release = NULL; context.copyDescription = NULL; int fileDesc = fileno(fp); return false; //not finished yet #else //USE_CFSOCKET static char oneLine[1024]; oneLine[0] = 0; do { fgets (oneLine, sizeof(oneLine), fp); } while( feof(fp) == 0 ); (void) pclose( fp ); return true; //finished #endif //USE_CFSOCKET } return true; //error condition. finished } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/vlubet% 40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I do not use send and recv directly, I use CFSocket abstraction which probably uses them. Does that mean that this code will break after Tiger? Or can I hope that CFSocket will be fixed to use read/write instead send/recv? I know it is kind of hackish to use CFSocketCreateWithNative on file descriptor but it works very well for me. Alternatives? Tom mFileDescSocket = ::CFSocketCreateWithNative( kCFAllocatorDefault, fileDesc, kCFSocketDataCallBack, PopenCFSocketCallback, &context); if(mFileDescSocket != NULL) { mSource = ::CFSocketCreateRunLoopSource (kCFAllocatorDefault, mFileDescSocket, 0); if(mSource != NULL) ::CFRunLoopAddSource( ::CFRunLoopGetCurrent(), mSource, kCFRunLoopDefaultMode ); } This email sent to vlubet(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel log: app uses send/recv on a pipe
by Tomasz Kukielka 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AccT3Lcp9aJXFX/PEdunVQAX8i08Wg== Thread-topic: Kernel log: app uses send/recv on a pipe User-agent: Microsoft-Entourage/11.2.5.060620 I do not use send and recv directly, I use CFSocket abstraction which probably uses them. Does that mean that this code will break after Tiger? Or can I hope that CFSocket will be fixed to use read/write instead send/recv? I know it is kind of hackish to use CFSocketCreateWithNative on file descriptor but it works very well for me. Alternatives? Tom On 11/29/06 9:26 AM, "Vincent Lubet" <vlubet(a)apple.com> wrote: > This message is there to alert developers they should not use sockets > system calls like send() and recv() on pipes as pipes are no more > backed by sockets since Tiger 10.4. > > You should use write() and read() instead. > > Vincent > > > On Nov 28, 2006, at 10:38 PM, Tomasz Kukielka wrote: > >> Hi, >> I noticed the following kernel message in system log: >> >> Nov 28 20:10:42 TK-MB kernel[0]: CommandDroplet[1993] uses send/ >> recv on a >> pipe >> >> CommandDroplet is the application that I develop as part of >> OnMyCommand >> which wraps Unix or AppleScript scripts with some GUI. I have been >> experimenting with it recently trying to make popen execution non- >> blocking. >> The problem is with pipe caching (you cannot work it around) which >> locks the >> reading and you get stuck in in fread (or fgets). I wanted to >> improve it but >> nothing seemed to work until I created a CFSocket on the file >> description >> from the stream. It works beautifully as a CFRunLoop source - >> providing a >> data in callback and not blocking. >> But the kernel message is a signal that there might be something >> wrong with >> it. See below for the code I used. When I #undef USE_CFSOCKET the >> kernel >> does not complain. I would really hate to go back to the previous >> synchronous/blocking code. >> >> Thanks, >> Tom >> http://www.abracode.com/free/cmworkshop/ >> >> >> >> bool >> POpenExecutor::Execute( const char *inCommand ) >> { >> if(inCommand == NULL) >> return true; >> >> FILE *fp = popen( inCommand, "r" ); >> if ( fp != NULL ) >> { >> #ifdef USE_CFSOCKET >> >> CFSocketContext context; >> context.version = 0; >> context.info = this; >> context.retain = NULL; >> context.release = NULL; >> context.copyDescription = NULL; >> >> int fileDesc = fileno(fp); >> >> mFileDescSocket = ::CFSocketCreateWithNative( >> kCFAllocatorDefault, >> fileDesc, kCFSocketDataCallBack, >> PopenCFSocketCallback, >> &context); >> if(mFileDescSocket != NULL) >> { >> mSource = ::CFSocketCreateRunLoopSource >> (kCFAllocatorDefault, >> mFileDescSocket, 0); >> if(mSource != NULL) >> ::CFRunLoopAddSource( ::CFRunLoopGetCurrent(), >> mSource, >> kCFRunLoopDefaultMode ); >> } >> >> return false; //not finished yet >> >> #else //USE_CFSOCKET >> >> static char oneLine[1024]; >> oneLine[0] = 0; >> do >> { >> fgets (oneLine, sizeof(oneLine), fp); >> } >> while( feof(fp) == 0 ); >> >> (void) pclose( fp ); >> >> return true; //finished >> #endif //USE_CFSOCKET >> >> } >> >> return true; //error condition. finished >> } >> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/vlubet% >> 40apple.com >> >> This email sent to vlubet(a)apple.com > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel log: app uses send/recv on a pipe
by Vincent Lubet 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com You should use write() and read() instead. Vincent On Nov 28, 2006, at 10:38 PM, Tomasz Kukielka wrote: Hi, I noticed the following kernel message in system log: Thanks, Tom http://www.abracode.com/free/cmworkshop/ bool POpenExecutor::Execute( const char *inCommand ) { if(inCommand == NULL) return true; FILE *fp = popen( inCommand, "r" ); if ( fp != NULL ) { #ifdef USE_CFSOCKET CFSocketContext context; context.version = 0; context.info = this; context.retain = NULL; context.release = NULL; context.copyDescription = NULL; int fileDesc = fileno(fp); return false; //not finished yet #else //USE_CFSOCKET static char oneLine[1024]; oneLine[0] = 0; do { fgets (oneLine, sizeof(oneLine), fp); } while( feof(fp) == 0 ); (void) pclose( fp ); return true; //finished #endif //USE_CFSOCKET } return true; //error condition. finished } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This message is there to alert developers they should not use sockets system calls like send() and recv() on pipes as pipes are no more backed by sockets since Tiger 10.4. Nov 28 20:10:42 TK-MB kernel[0]: CommandDroplet[1993] uses send/ recv on a pipe CommandDroplet is the application that I develop as part of OnMyCommand which wraps Unix or AppleScript scripts with some GUI. I have been experimenting with it recently trying to make popen execution non- blocking. The problem is with pipe caching (you cannot work it around) which locks the reading and you get stuck in in fread (or fgets). I wanted to improve it but nothing seemed to work until I created a CFSocket on the file description from the stream. It works beautifully as a CFRunLoop source - providing a data in callback and not blocking. But the kernel message is a signal that there might be something wrong with it. See below for the code I used. When I #undef USE_CFSOCKET the kernel does not complain. I would really hate to go back to the previous synchronous/blocking code. mFileDescSocket = ::CFSocketCreateWithNative( kCFAllocatorDefault, fileDesc, kCFSocketDataCallBack, PopenCFSocketCallback, &context); if(mFileDescSocket != NULL) { mSource = ::CFSocketCreateRunLoopSource (kCFAllocatorDefault, mFileDescSocket, 0); if(mSource != NULL) ::CFRunLoopAddSource( ::CFRunLoopGetCurrent(), mSource, kCFRunLoopDefaultMode ); } _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/vlubet% 40apple.com This email sent to vlubet(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

kdebug_chudhook: need finer grained kdebug
by Robert Kueffner 29 Nov '06

29 Nov '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, the kdebug trace facility provides kernel event logs via typedef struct { uint64_t timestamp; unsigned int arg1; unsigned int arg2; unsigned int arg3; unsigned int arg4; unsigned int arg5; /* will hold current thread */ unsigned int debugid; } kd_buf; Any help is greatly appreciated! Thanks, Robert _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Logs sampled over some time interval are retrieved by existing commands (sc_usage, latency etc) and a program described in Singh's OSX internals, Fig 6-39. The value of the debugid-field denotes the invocated function, corresponding names given in /usr/share/misc/trace.codes MY PROBLEM 1) I need to extract the particular parameters and returned values, say in the case of MACH calls. 2) I need to perform actions immediately after starting/before finishing an operation, instead of just processing logs I found that (mig generated) messages requesting (as well as replying to) the operations are also traced. arg1 & arg3 give the message address in memory and its size. At the time logs are retrieved the contents of these messages is most likely lost, though, so parameters etc are not available. SOLUTION? A solution could be to register a kdebug_chudhook() callback to retrieve the logs including the messages during their transmission. As far as I understood, CHUD itself does not seem to export this. (although chudMaxKDebugTraceSampleLimitCallback() sounds related, an undocumented funtion from chudKDebugTrace.h) Does anybody know how to register a kdebug_chudhook() callback? (I am aware this would be a kernel context callback that must not be messed up) Is there a more straightforward solution? This email sent to site_archiver(a)lists.apple.com

1 0