December 2006 - Darwin-kernel

Re: Notification of fork()
by Michael Smith 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 26, 2006, at 10:55 AM, Josh Rodatus wrote: I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? = 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.… That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. When you override, you are copying your custom function into the kernel's permanent memory. Your custom function will *not* be erased along with your kext (during unload). The kernel's "permanent memory" is completely full of bits of the kernel, so wherever it might go that ain't it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Josh Rodatus 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? Sounds convoluted, but it still could be an option. ~ Josh On Dec 26, 2006, at 1:38 PM, Curtis Jones wrote: Albeit somewhat brute-force, Jonathan Rentzsch's mach_override can solve a lot of tough problems. With some adaption, you could use it to override the kernel's pset_add_task(processor_set_t pset, task_t task) or similar function with your own version. In this case you would simply get the needed information out of the task_t before calling the real pset_add_task. That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? -- Curtis Jones _______________________________________________ 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.… When you override, you are copying your custom function into the kernel's permanent memory. Your custom function will *not* be erased along with your kext (during unload). You would have to have a status bit in memory that indicates whether or not your kext is loaded, so that your override function would know whether or not it should perform the custom operations. On 12/26/06, Josh Rodatus <josh(a)rodatus.com> wrote: Since mach_override would need adaption for use within the kernel, and it's also processor-dependent, you could write your own special-purpose overriding routine based on the same principles. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Curtis Jones 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HD2A5tZ7M7kGn0hzjpC5HcasvsZc7VTjxfJEPB6tNewNv1An5hJo7LbmqNuI/+0THrxtUKJ6nf+6Uw148Wi3N9WDU8th1pPn8NtH26DdrftYIDq8QW4Od7r6xajmVnlawWVU4k57vnrP1Y9wf6eWkF0Z1bMqCqSlC6D0m1A4up0= Albeit somewhat brute-force, Jonathan Rentzsch's mach_override can solve a lot of tough problems. With some adaption, you could use it to override the kernel's pset_add_task(processor_set_t pset, task_t task) or similar function with your own version. In this case you would simply get the needed information out of the task_t before calling the real pset_add_task. Since mach_override would need adaption for use within the kernel, and it's also processor-dependent, you could write your own special-purpose overriding routine based on the same principles. That is very interesting. I'm looking at it right now. Certainly it is more invasive than what I had in mind, but I'm not really in a position to be picky if it works. I noticed in the documentation that he intends to one day add "mach_unoverride" support. So, what does this mean when my kext unloads? -- Curtis Jones _______________________________________________ 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.… On 12/26/06, Josh Rodatus <josh(a)rodatus.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Josh Rodatus 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Any chance that there is a way in which my kext can be made aware when a fork() occurs? I'm using kauth for purposes of exec() ... but it definitely doesn't appear to be applicable to simply fork()'ing. More generally, I would be content with simply knowing when a new process started. My real purpose: I'm trying to associate a process id and/or path-to-executable with incoming socket connections in my socket filter - as early in the process (ideally in the connect callback performed in the context of the listener) as possible. I use kauth so that I can (in limited but sufficient circumstances) know the path-to-executable for various processes. When one of those processes creates a listener, I can associate the two together. When that listener gets an incoming connection and the connect() callback is called in the context of that listener, I can then associate that incoming connection with a particular process ... until the annoyance of fork()'ing enters the picture. If I knew when fork() was called and the new pid, I could associate that new process with its parent process, and all would be well. Anyway ... I'm open to suggestions. Obviously if this were all working out the way I wanted it to, I wouldn't be posting this. ~ Josh _______________________________________________ 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.… Albeit somewhat brute-force, Jonathan Rentzsch's mach_override can solve a lot of tough problems. With some adaption, you could use it to override the kernel's pset_add_task(processor_set_t pset, task_t task) or similar function with your own version. In this case you would simply get the needed information out of the task_t before calling the real pset_add_task. Since mach_override would need adaption for use within the kernel, and it's also processor-dependent, you could write your own special-purpose overriding routine based on the same principles. This email sent to site_archiver(a)lists.apple.com

1 0

Re: implementing an AudioIOFunction
by Josh Rodatus 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com ~ Josh _______________________________________________ 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.… The problem is that you are introducing latency into the process, probably because you are serialising the audio output behind some or all of your display code. To be honest I don't exactly know what you mean by serializing audio output behind the display code, but besides the socket communication I'm definitely not copying blocks of samples during the processing. Even so, the computer's audio stream isn't dependent upon the speed of the process that does the processing/displaying in any way (that I know of). It sounds like what you want is a tap on the output, not to actually be blocking the output path. Also, you definitely don't want to be doing any real work on the output thread. Without changing your model too much, the best suggestion I have is for you to implement a lossy buffer (a ring of some sort) in memory supplied via a userclient, and just copy into that ring while you're copying from input to output. I still don't think that's as good as a straight tap would be, but I'm afraid I don't know enough about the audio stack to know how you'd go about getting there. Thank you for that suggestion. Would I use an IOMemoryDescriptor to share that user-space ring buffer? I must admit I'm new to kernel programming. When you say "straight tap", do you mean like asynchronously calling IOAudioEngine::getCurrentSampleFrame()? That may introduce some new complications, but is an interesting idea. On Dec 26, 2006, at 4:23 AM, Michael Smith wrote: The problem is that you are introducing latency into the process, probably because you are serialising the audio output behind some or all of your display code. It sounds like what you want is a tap on the output, not to actually be blocking the output path. Also, you definitely don't want to be doing any real work on the output thread. Without changing your model too much, the best suggestion I have is for you to implement a lossy buffer (a ring of some sort) in memory supplied via a userclient, and just copy into that ring while you're copying from input to output. I still don't think that's as good as a straight tap would be, but I'm afraid I don't know enough about the audio stack to know how you'd go about getting there. = Mike This email sent to site_archiver(a)lists.apple.com

1 0

Re: implementing an AudioIOFunction
by Josh Rodatus 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com ~ Josh _______________________________________________ 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.… How often are you writing to the socket and ow much data are you writing? My first guess would be that your writing so often that the constants calls out to the driver is causing the system to stutter. I'm writing 2048 bytes of data every time the audio stream calls my AudioIOFunction function, about every 1/100 of a second. Also, since it sounds like your an IOKit driver, why are you using a socket rather than the native IOUserClient techniques? Not an IOKit driver. My kext is of the same form as Apple's "Hello World" kernel extension example - simply a start and a stop function. Since it sounds like IOUserClient might be what I'm looking for, I'll write a version of the kext in driver form to try it out. On Dec 25, 2006, at 11:31 PM, Kevin Elliott wrote: How often are you writing to the socket and ow much data are you writing? My first guess would be that your writing so often that the constants calls out to the driver is causing the system to stutter. Also, since it sounds like your an IOKit driver, why are you using a socket rather than the native IOUserClient techniques? This email sent to site_archiver(a)lists.apple.com

1 0

Finding Kernel Extension Developers
by Frank Thomas 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=naRtrEMdczSgLCjAk6laDXAq32BX+04mXdpEAkOwpUambDGJrXHhveo5jFRS4T0MtjoQWm0hvvJK+c2THwZeM3BUcxi/OBoOTSMFJQDH8BtaTnvY8tPcLUDNM6kh/g23Gn0g0QYpJCOmxInyQNvpfnzsdawoYVN4c7j8QPQxzsg= _______________________________________________ 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: Notification of fork()
by Michael Smith 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 25, 2006, at 9:26 PM, Curtis Jones wrote: Any chance that there is a way in which my kext can be made aware when a fork() occurs? I'm using kauth for purposes of exec() ... but it definitely doesn't appear to be applicable to simply fork()'ing. More generally, I would be content with simply knowing when a new process started. My real purpose: I'm trying to associate a process id and/or path-to-executable with incoming socket connections in my socket filter - as early in the process (ideally in the connect callback performed in the context of the listener) as possible. I use kauth so that I can (in limited but sufficient circumstances) know the path-to-executable for various processes. When one of those processes creates a listener, I can associate the two together. When that listener gets an incoming connection and the connect() callback is called in the context of that listener, I can then associate that incoming connection with a particular process ... until the annoyance of fork()'ing enters the picture. If I knew when fork() was called and the new pid, I could associate that new process with its parent process, and all would be well. Anyway ... I'm open to suggestions. Obviously if this were all working out the way I wanted it to, I wouldn't be posting this. = 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.… It sounds to me like you might want to try locating an unknown process' parent at listen time; typically if someone forks and attempts to do real work in the forkee, they aren't going to reparent since they are working closely coupled. This might still break in the case where the listener is created in a parent but the accept happens in the child, but that depends on what other assumptions you're making. This email sent to site_archiver(a)lists.apple.com

1 0

Re: implementing an AudioIOFunction
by Michael Smith 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 25, 2006, at 7:21 PM, Josh Rodatus wrote: = 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.… As I mentioned earlier, my user-space program is a music beat visualizer. It merely needs read access to the outbound audio stream, and it gets it from my kernel extension. No audio is sent back to the kernel. To minimize latency, all the AudioIOFunction does is send the samples over a socket to my program - no preprocessing. You will find the source code and more detail in one of my previous posts in this thread. So once again my problem is this. The client program is using very little CPU, yet the system audio stutters when I even as much as activate a window. So I conclude that using a socket to transfer the samples from kernel to program isn't efficient enough, and am in search of an alternative. The problem is that you are introducing latency into the process, probably because you are serialising the audio output behind some or all of your display code. It sounds like what you want is a tap on the output, not to actually be blocking the output path. Also, you definitely don't want to be doing any real work on the output thread. Without changing your model too much, the best suggestion I have is for you to implement a lossy buffer (a ring of some sort) in memory supplied via a userclient, and just copy into that ring while you're copying from input to output. I still don't think that's as good as a straight tap would be, but I'm afraid I don't know enough about the audio stack to know how you'd go about getting there. This email sent to site_archiver(a)lists.apple.com

1 0

Notification of fork()
by Curtis Jones 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=bYldjpiaaJcz/D6YOPsqD1AnNDq8WZtVPs1TrUlNbninUFspW09+tb5yImlTKScZntbudCNSx2cU/Jl/wpTb3qdEKYVKQxQKpWglMqxqurWuaeNLCCv7Lwc6jX5gFuHDpY48R+atT5magl7t90tw09kcvNWqViim4xJAj9WeqO8= Any chance that there is a way in which my kext can be made aware when a fork() occurs? I'm using kauth for purposes of exec() ... but it definitely doesn't appear to be applicable to simply fork()'ing. More generally, I would be content with simply knowing when a new process started. My real purpose: I'm trying to associate a process id and/or path-to-executable with incoming socket connections in my socket filter - as early in the process (ideally in the connect callback performed in the context of the listener) as possible. I use kauth so that I can (in limited but sufficient circumstances) know the path-to-executable for various processes. When one of those processes creates a listener, I can associate the two together. When that listener gets an incoming connection and the connect() callback is called in the context of that listener, I can then associate that incoming connection with a particular process ... until the annoyance of fork()'ing enters the picture. If I knew when fork() was called and the new pid, I could associate that new process with its parent process, and all would be well. Anyway ... I'm open to suggestions. Obviously if this were all working out the way I wanted it to, I wouldn't be posting this. -- Curtis Jones curtis.jones(a)gmail.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