At 13:08 +0100 11/4/03, Quinn wrote: Ah. You're not the first developer to hit this. This has been answered by DTS before. I'm not 100% sure of the current recommendation. I'll check up on this and get back to the list. Here's the current advice from the DTS I/O Kit experts on this topic. He has two options (beside the skanky try-to-read-a-file-in-the-kernel): 1. Write a userland process that downloads the firmware. This means that there must be some property in the I/O Registry that differs between the "raw" device state (no firmware) and the firmware-uploaded state. The example /Developer/Examples/IOKit/usb/Ezloader\ Example shows how to do this for certain USB devices. If the bus family for his device doesn't provide user client access, he can use the I/O Registry as a communications pipe if the firmware isn't too large. The DTS sample VendorSpecificType00 shows how to do this. Of course, if he has a custom kernel driver, he can write a user client for it to provide a way to send firmware to the kernel. 2. If he wants to do this from the kernel, he can write a utility that reads his firmware file and generates a C source file with that firmware encoded as a character array. He then would build a subkext with a ::start routine that loads the firmware into his device and returns NULL. This subkext would match to his device in its uninitialized state. The fact the driver fails to start will cause it to be unloaded from the kernel after about a minute. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.