Slashdot Mirror


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?"

2 of 12 comments (clear)

  1. One workaround by coyote-san · · Score: 3

    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.

    --
    For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
  2. Licensing complications, and why bother anyway? by JoeBuck · · 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.