Re: Write/Read Bulk communication process in KEXT. How?
Re: Write/Read Bulk communication process in KEXT. How?
- Subject: Re: Write/Read Bulk communication process in KEXT. How?
- From: Terry Lambert <email@hidden>
- Date: Wed, 24 May 2006 12:58:29 -0700
On May 24, 2006, at 11:52 AM, Andrew Gallatin wrote:
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.
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?
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.
At least 3 other OSes provide a way for drivers
to load firmware easily:
Windows' NdisOpenFile / NdisMapFile:
Reads files from in the kernel.
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.
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?
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.
-- Terry
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden