site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- 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 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@lists.apple.com