File Access In Kernel Modules? 12
gibson_81 asks: "I'm writing a device driver for a really ugly piece of hardware: it needs me to read in firmware from a file before I can initialize it. For now, I force the user-program to read the entire file into memory and pass that memory buffer as an IOCTL argument, but that's even uglier than the hardware. None of the documents on writing kernel device drivers have mentioned how to access files from the kernel, but some source-grepping led me to sys_open ... which was not exported to modules :( So, I ask you, the Slashdot community: do you know what functions I can use to do this, or is it a no-no?"
Kernel mailing lists (Score:1)
Re:Licensing complications, and why bother anyway? (Score:1)
Re:Kernel mailing lists (Score:1)
I've written (and patched) a few device drivers before, but never needed to do what he described in the question... I'm intrigued into what the device is, and who cobbled it together.
Question's off, but ... (Score:1)
what's the device? (Score:1)
make another devfs entry (Score:2)
This can simply be to a buffer in kernel memory.
Then the firmware can just be catted into this file, from startup scripts, or I think you can get modutils to run a script for you after you insert your module.
If you are targeting 2.2, use a
Repeat after me:
ioctl is evil!
been there done that. (Score:2)
http://zurk.sourceforge.net..look for the pda driver.
Re:Licensing complications, and why bother anyway? (Score:2)
The unanimous agreement of everyone in a position to complain is that there is no meaningful difference between opening a file to load it into the device and copying an embedded image into the same device. If anything, they prefer the latter since it eliminates a possible source of data corruption (and hence reduces their support costs).
What did worry them was the possibility that *their* firmware would also suddenly be covered by the GPL if it is loaded by the kernel. This is the logical conclusion to your reasoning -- and why some major corporations had refused to permit employees to use "emacs" in the past. (If someone uses emacs to edit a file, isn't the results a "derived" work?)
That argument falls on its face because it's too extreme. Once you accept that the exact mechanism for loading the firmware image is not significant, you find that the "data is GPL'd" argument would also apply to the contents of a file server, mail server, print server, etc.
SoundBlaster AWE WaveTable (Score:2)
Marcus
How FreeBSD does it (Score:2)
FreeBSD has a splash screen/screen saver kernel module that displays an arbitrary bitmap (from a file) to the user. In order to specify the image to load you do something similar to:
kldload splash
kldload spash-image.bmp -t splash_image_data
The second line flags the first file as a data item. I don't know if Linux can do the same though, as I've never used it.
--
Eric is chisled like a Greek Godess
One workaround (Score:3)
In the meanwhile, provided the firmware doesn't change frequently you can always include a copy of it in your module! Basically, write a small program that reads the file and converts it into C code, e.g.
static const char firmware[] = { 0x23, 0x11, 0x85,... }
You can then compile this into your module. If you want to be fancy, you can wrap the whole mess in the __init tag (IIRC) and it will only be in core long enough to initialize the system.
Even if the module changes regularly, you can create one module which contains nothing but this firmware image, and a second that will read the first (if present) and initialize the controller. You may be able to play games that allow you to subsequently remove the firmware image module.
Licensing complications, and why bother anyway? (Score:4)
Compiling the firmware into the module may not be allowed, depending on the copyright on the firmware (you're making a derivative work of the firmware, which may be restricted by the firmware's license); in any case, this approach would make it illegal to compile the driver into the kernel (as, presumably, the firmware's license is not GPL-compatible).
I don't see the problem, though, with the IOCTL approach. Why not have a function that loads the firmware from memory? It seems like a flexible approach. To load the firmware from a file it's basically two calls, an mmap to make the file look like memory, and then the ioctl to load it. Why go through the pain of making the kernel do file I/O?
The ioctl approach is more hacker-friendly, as it allows users to experiment with different firmware more easily.