May 2010 - Darwin-kernel - lists.apple.com

Using OSKextRequestResouce from kext init routine?
by Ken Hornstein 14 May '10

14 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I'm having an issue with using OSKextRequestResouce(), specifically from my kext initialization routine. This function is unfortunately not well documented (hey, if there's documentation for it, point me to it!), but ... it seems like you can't use it from a kext initialization routine. More specifically, you can't expect the callback to be called until after your initialization routine exits (actually, it's worse than that, from what I can tell; I have a bunch of kexts that depend on each other, and none of the callbacks are called until after they all finish loading and are started). Is my understanding correct? (I would guess that's more of a limitation in kextd). --Ken _______________________________________________ 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

problems with modifying payload in iff_input_func
by Andy Huang 13 May '10

13 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=TURJqZubQEz2iTWgFdnsFACwE2aFyQ5wHK1EwjN0kIY=; b=BmjjuGWMk3sQ9A0J6TyboKJihnALhhP53eyBDYTtND1C4eUQamB1UfX8I8iqOoZZAF hG6evcli9A1XtENRk7pVa5oTIC/j+l8kHRP7KpP7XNiIShLIMD/4oN94wZ1D+S69L5Gn 6T9tKz7irv3qe2DMITgM8hMrNoCk8WKL4+NHc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XfmiquH9Nkb39E9fXPYm8WaVNAsYZhVzR8tO8uzfAPnvJCB0n9giEWuR5PWB9owED7 tfakZj+tKREUrfPGBWrleBEpmgwrfob3BiJ3MWvPqehz4s6T8cqgLZZdPMvZWL7mCdt/ BXK8RzrMWzV0B1S6atz9DvSprQP4uEnlcoGuA= _______________________________________________ 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: processor_info x86 perf. counters
by Wade Tregaskis 13 May '10

13 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com > What's the best way to access the performance counters programmatically ? It's not exactly programmatic, or at least not necessarily in the way you mean, but, Shark. Note however that Shark will not work on the open source kernel. Wade _______________________________________________ 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

cache affinity scheduling in new processors
by Alejandro 13 May '10

13 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.24 (Macintosh/20100228) _______________________________________________ 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

processor_info x86 perf. counters
by ray dhurandhar 13 May '10

13 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=ckvcXAZ0wd0j7//deD8f/RhSptbFYRwzrOqJNI7kD2E=; b=pKT6RN5ngwPgr8wFF8h++0fTavhtcc8CtBOieiOklhti+sru9UEzO1StTQLpZcd5rS y+nHOXoDTPTYRa+91mWOLFOje4S8BUc1Orjd0pvP7uRPV6su4x/iL0yQZgPIuSMap+81 BbAHSX7/aPb9/xziOQFrYJwPyoFKgp4QDRd04= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qT8KACUGNFHaIUgIKO/XifbicfdninaD4/5MWV9n2NqF0uthSe47ypWxBWeYxKQ/ze sowxjv+6cshmzPyf1ZX5UwMIUOvTBystz3QM0I2TPgcfzhj5SBK/qn5RZI2aooQCndhV r1joOH3Lv38d5hMFfMDblRlSz4IM+wx0fSJQk= _______________________________________________ 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: kextload failure on 10.5
by Terry Lambert 06 May '10

06 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, I wasn't suggesting you do that. I was suggesting that you build the 64 bit KEXT with the 10.6 SDK but everything else with the 10.4 SDK. Regards, -- 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.… On May 6, 2010, at 3:42 PM, Chris Suter wrote: On Fri, May 7, 2010 at 8:38 AM, Terry Lambert <tlambert(a)apple.com> wrote: You really have to consider the consequences of doing something like building a 10.6-and-later-only 64 bit KEXT with 10.4 header files in scope instead of 10.6 header files in scope. Per this reference: <http://developer.apple.com/mac/library/samplecode/AppleSamplePCI/index.html > ? The -isysroot isn't positionally bound to the -arch on a single line compiler invocation. This is why he got the multiple specification error in the first place. If he moves to building with XCode, it will handle everything behind the curtain for him (you and I both know what's behind that curtain), but without that, he will need to do the lipo, if he insists on using a Makefile and generating it via a command line make. As unthinkable as it is to not use XCode, I personally build a number of my KEXTs with command line tools as well. I avoid telling people about exactly how I do it because if I did that, someone would run GNU configure on something and it would statically decide that the source code byte order was equal to the byte order on the host machine, and their code would not end up working on the alternate byte order architecture(s). Tools which try to localize code for a single target architecture like that are bad news. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Importance of testing Kexts on differing hardware platforms
by Terry Lambert 06 May '10

06 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -- 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.… On May 5, 2010, at 5:20 PM, Martin Hardman wrote: I have a Kext (NKE) nearly ready for my QA team to test, the target hardware is any/all laptops running Snow Leopard (not iMacs, mac minis, or towers etc.) >From my observations with an equivalent product on Windows, it is apparent components at this kernel level of the OS can be effected by the eco-system i.e. the software may run perfectly fine on one laptop but put it on another and a defect comes to light (each window laptop has different drivers from different vendors etc. etc. which must shift the footprint of memory, speed, interaction, interference etc. Making testing on a wide range of hardware important to be confident of a bug free product). However does such a similar situation and variance exist with the Mac line? If an NKE is tested and found to be bug free on an mac mini a guarantee, or a very strong indication, that it will be bug free on an air book or a mac book etc.? (Right now we only have Mac minis, I’ve trying to determine if we can stick with these, or its necessary to purchase more expensive laptops for testing purposes). I would add to what Mike S. said by saying that testing on a single, small memory platform isn't going to find issues like 32 bit pointer truncation of memory addresses in excess of 4G, and it's not going to find similar issues. You aren't going to find most of the similar issues through ad-hoc testing, without contriving some way for the address to be over the 4G boundary. For some hardware, you're also going to find that the buffers need to be bounced (i.e. you need to specifically request their allocation below 4G or below 2G physical), because the hardware involved is unable to address physical memory beyond some limit based on its address lines. This is also generally not findable through ad-hoc testing. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kextload failure on 10.5
by Chris Suter 06 May '10

06 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi Terry, On Fri, May 7, 2010 at 8:38 AM, Terry Lambert <tlambert(a)apple.com> wrote: > You really have to consider the consequences of doing something like > building a 10.6-and-later-only 64 bit KEXT with 10.4 header files in scope > instead of 10.6 header files in scope. I wasn't suggesting you do that. I was suggesting that you build the 64 bit KEXT with the 10.6 SDK but everything else with the 10.4 SDK. Kind regards, Chris _______________________________________________ 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: kextload failure on 10.5
by Terry Lambert 06 May '10

06 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Well, that's what happens, but you don't actually need to do it yourself—the build process does it for you (same as for everything else). Exactly—and I can't think of much that isn't available in 10.6 (32 bit) that was available in 10.4. Obviously, it's a bit different for x86_64 but that won't be running pre-10.6 so that's not a problem. -- 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.… On May 3, 2010, at 6:51 PM, Chris Suter wrote: On Tue, May 4, 2010 at 11:44 AM, Ryan Hankins <rqh(a)small-tree.com> wrote: So, you must be able to glue the two things together with the lipo command once they've been built against separate SDKs... interesting. In other words, as long as you are supporting only 10.4 APIs (that are still available on 10.6), you can do this. Of course, this will skip the symbol renaming that he ran into in the first place, which means that his code will not be aware of any double unlocks it does, and so any bugs of that type will ship with his product, rather than being fixed. At some point in the future, we will drop support for the unrenamed compatibility symbol, on the assumption that people have been targetting the renamed symbol long enough that this is not an issue. At that point, his driver will start failing to load with an unresolved symbol for the unlock code. So he will have a perfectly good 10.6 driver that would have worked on a future version of the OS, had he *NOT* defeated the symbol renaming. You really have to consider the consequences of doing something like building a 10.6-and-later-only 64 bit KEXT with 10.4 header files in scope instead of 10.6 header files in scope. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Importance of testing Kexts on differing hardware platforms
by Rick Macklem 06 May '10

06 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Wed, 5 May 2010, Michael Smith wrote: That being said, without knowing a great deal more about your code, it's hard to give you a solid answer. Do you know what your external dependencies look like? How about uni- vs. multi-processor behaviour in your code? Are you likely to be sensitive to substantial performance differences? Multiple network interfaces? Network mobility? Add-in and USB network adapters? Just as a data point for my case, which is an NFSv4 client, there has only been one issue w.r.t. different Macs. On some, the default 128Kbyte read/write data size works fine, but on others, it has to be reduced to 32Kbytes or the read/write performance is very poor. I suspect this is caused by the net device driver not handling large bursts of received packets well, but I don't know for sure. rick _______________________________________________ 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