File Access In Kernel Modules?

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

[Paul Carver]

Isn't this a topic for one of the kernel mailing lists? Slashdot really isn't your best source of specific programming knowledge. I think you'll find that the vast majority of Slashdot readers (including myself) have never written any kernel or device driver code.

Re:Licensing complications, and why bother anyway?

[jimduchek]

Modules don't have to be GPL, so that's not an issue. Only trick to remember is you can't steal code from GPL'd modules if you're gonna do this :) On the other hand, I don't think it would violate the GPL anyway, since the firmware code, to the kernel module, is simply data and not executable code, so I think you could get away with a GPL'd module. Jim

Re:Kernel mailing lists

[Tower]

Yeah - this isn't the quickest spot to get answers for that [insert whining about how it used to be better].

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 ...

[gibson_81]

...thanx for the replies anyway :) as soon as I compiled the code into the kernel, rather than running it as a module, open() and close() worked fine ... the hardware is a propriatery image scanner, used by the company I work for in their gaming terminals, so licenses are not a problem :) the firmware is now loaded as a file, which the kernel reads in before starting init() ... anyhow, I think a paper on how to make your module a part of the kernel source tree (with corresponding options in make *config and the Makefiles) is something that needs writing ... if no-one has done it before I get more time on my hands, the author might even be me *s*

what's the device?

[chowda]

out of curiosity...

make another devfs entry

[listen]

Make another entry in devfs.
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 /proc file.

Repeat after me:
ioctl is evil!

been there done that.

[Zurk]

my drive does it - beware pre alpha untested code!
http://zurk.sourceforge.net..look for the pda driver.

Re:Licensing complications, and why bother anyway?

[coyote-san]

The only problem with this analysis is that (IIRC) it's already been dismissed. Unfortunately I can't recall where I read the discussion, but someone has presented this exact question to several hardware manufacturers.

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

[mrossbrown]

The SB AWE-WAVE kernel module uses the principle you described in your question. You can load the driver, but you must use userspace utilites to load SoundFonts and instruments for MIDI playback. I think that would be the best way to approach it (reading in a file and calling an ioctl on the driver), because if your firmware is updated all you have to do is load a new file, not recompile and reship a new module.

Marcus

How FreeBSD does it

[hodeleri]

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

[coyote-san]

If you read a file, it will probably be through the VFS layer with the file read into disk buffer blocks. I've played around with this just enough to be dangerous....

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?

[JoeBuck]

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.