site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On May 24, 2006, at 11:52 AM, Andrew Gallatin wrote: This comes up over, and over, and over again here. Is there any chance Apple can provide a centralized way to do this in the OS, so we don't all have to use our own home grown and (potentially) buggy or wasteful mechanisms? At least 3 other OSes provide a way for drivers to load firmware easily: Windows' NdisOpenFile / NdisMapFile: Reads files from in the kernel. Linux: request_firmware(): Signals a centralized user-space daemon (udev) to copy firmware image file into the kernel. FreeBSD: firmware(9) Makes it easy to wrap a firmware image in a loadable module, and allows a driver to easily load and unload the module on demand via firmware_get() and firmware_put(). These are something that it'd probably be useful to explore. Have you file a bug report requesting this? -- Terry Drew _______________________________________________ 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... Terry Lambert writes: If you need to do file I/O to load firmware (as an example), either put the firmware in a discardable section (vm_deallocate() it after it's loaded in the card), or have a user space daemon communicate the firmware to your driver via a series of ioctl() calls to push the data *temporarily* into the kernel, so it doesn't take up real or virtual memory in your driver. The normal way people avoid having to load the firmware from their driver is with a ROM. 8-). The normal way people support updating firmware is to replace that ROM with flash. For vendors which only put RAM on their hardware, and don't include either ROM or flash, the normal way you deal with this on MacOS X is to have a helper application in user space, and push the data down into the kernel from user space to the driver into a space temporarily allocated by the driver, and then discard the memory once it's loaded into the card. The proper way to do this is the Windows kernel is actually to mark the firmware section as "INITIALIZED_DATA" and "MEM_DISCARDABLE| MEM_READ" in the Portable Executable file (actually, extended COFF). Then when it's loaded in with PELoader, it's used during the init process, and then it's thrown away (exactly what would happen if you #pragma'ed it into it's own section in your KEXT to put it on a page boundary, and then called vm_deallocate() on it when you are done with it. Normally, Microsoft recommends against doing file I/O from their kernel as well. Realize that external bug reports get a lot more attention than ones Apple engineers file as "this would be cool", since external bug reports tend to be customer problems in search of a solution, rather than engineering solutions in search of a customer problem. This email sent to site_archiver@lists.apple.com