RE: open file in kernel model

["Riley Williams" <Riley@Williams.Name>]

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