open file in kernel model

open file in kernel model

[JinuM]

Hi,

Can anyone help me with this simple problem.

I am trying to write a firmware loader driver. Instead of reading the
firmware as a buffer(predefined array)  we would like to read the firmware
from a file (say /root/firmware). Do we have some function which reads the
file contents in kernel mode.

-Jinu

Re: open file in kernel model

[Riley Williams]

Hi Jinu.

 > I am trying to write a firmware loader driver. Instead of reading
 > the firmware as a buffer (predefined array)  we would like to read
 > the firmware from a file (say /root/firmware).

Are you assuming that there is only one piece of firmware to be loaded
in the entire system, or is this driver for a specific device?

 > Do we have some function which reads the file contents in kernel
 > mode.

There probably is (I'm no expert on that part of the system), but I
doubt using such a function is appropriate for your declared task:

 1. If this is a generic driver, it would probably need to handle
    multiple firmware blobs, so would need to have access to more
    than one file.

 2. Even if it is for a specific device, the filename it needs to
    read will vary from one system to another.

There have been quite a few discussions recently regarding firmware
loading in the kernel, and at least one major Linux distributor now
rips ANY "binary blobs" out of the kernel because of legal issues.
The kernel developers are essentially moving over to the following
general scheme:

 1. The kernel itself neither contains the "binary blob" that is the
    firmware, nor knows where to obtain it. This is the requirement
    to avoid several hot legal issues, and also allows any updated
    firmware to be installed far easier than any other method.

 2. The kernel provides an interface usable by any driver requiring
    firmware, where that driver can state its requirement. There are
    currently several candidates for this interface and it is unclear
    which will eventually be decided on.

 3. A usermode program checks that the relevant requirement has been
    met, then feeds the relevant firmware to the driver. /sbin/hotplug
    is apparently a prime candidate for this interface.

You may wish to consider such a scheme if you are working on a driver
for a particular device. From the driver's viewpoint, this basically
comes down to registering some means for a usermode program to supply
the driver with the relevant firmware. This could be an ioctl that the
usermode program can call with an open file handle as parameter, and
the driver then reads the contents of that file into the firmware, or
it could be a special node in the file system that the usermode program
writes to and the driver copies anything written to that file straight
into the firmware slot.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 6-May-2003

RE: open file in kernel model

[JinuM]

Hi Riley

[jinum]Thanx for the early reply.

Are you assuming that there is only one piece of firmware to be loaded
in the entire system, or is this driver for a specific device?

[jinum] This firmware is for a specific device.
What we plan to do is maintain the filename constant(say /home/firmware)
so if there is a change in the firmware we would overwrite this file.

[jinum]I am not sure of the leagal issue you are talking about. We want to
use it
for our device, hence it will not be under public release.

You may wish to consider such a scheme if you are working on a driver
for a particular device. From the driver's viewpoint, this basically
comes down to registering some means for a usermode program to supply
the driver with the relevant firmware. This could be an ioctl that the
usermode program can call with an open file handle as parameter, and
the driver then reads the contents of that file into the firmware, or
it could be a special node in the file system that the usermode program
writes to and the driver copies anything written to that file straight
into the firmware slot.

[jinum] we intended to load the firmware when our device is found.
We will not want a usermode application talking to driver for this.
The best solution would be to have kernel mode file functions 
equivalent to open,read,write n close.

-Jinu

RE: open file in kernel model

[Riley Williams]

Hi Jinu.

 > Thanks for the early reply.

NP.

One thing though: Are we talking about the Linux kernel or the ELKS kernel?
I didn't realise originally, but you posted your query to the ELKS list. If
you are indeed referring to Linux, you may wish to remove ELKS from the CC.

 > I am not sure of the legal issue you are talking about. We want to use
 > it for our device, hence it will not be under public release.

If you don't plan on ever releasing either the device or the driver for
public sale, there's no legal problem whatsoever. However, if at any future
date that situation changes, you would need to deal with the same issues,
largely brought up by the SCO/IBM legal challenge. It is usually better to
assume that such is the case rather than having to scrap your work because
it suddenly becomes the case when you didn't expect such.

 >> Are you assuming that there is only one piece of firmware to be loaded
 >> in the entire system, or is this driver for a specific device?

 > This firmware is for a specific device.

Nodz.

 > What we plan to do is maintain the filename constant (say /home/firmware)
 > so if there is a change in the firmware we would overwrite this file.

Probably more useful would be to have /home/firmware be a symlink to the
actual firmware, such that you can point it to a different file to see if
it works, and point it back if it doesn't, without risking losing the
original firmware. The file open/read/close routines follow symlinks
transparently to get to the actual file.

 >> You may wish to consider such a scheme if you are working on a driver
 >> for a particular device. From the driver's viewpoint, this basically
 >> comes down to registering some means for a user mode program to supply
 >> the driver with the relevant firmware. This could be an ioctl that the
 >> user mode program can call with an open file handle as parameter, and
 >> the driver then reads the contents of that file into the firmware, or
 >> it could be a special node in the file system that the user mode program
 >> writes to and the driver copies anything written to that file straight
 >> into the firmware slot.

 > we intended to load the firmware when our device is found. We will not
 > want a user mode application talking to driver for this. The best
solution
 > would be to have kernel mode file functions equivalent to open, read,
 > write and close.

Those functions exist, but there are apparently problems using them from
kernel context as they expect to see a user mode process number for the
security checks they have to carry out, and no such process number exists
in kernel mode.

One thing you may wish to investigate is the "Firmware File System" that
recently appeared on the Linux Kernel mailing list, and the discussion that
followed, which Linus was quite an active participant in.

Best wishes from Riley.
---
 * Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 6-May-2003