RE: Reading a file inside the device driver.

From: Richard B. Johnson (root@chaos.analogic.com)
Date: Fri Jul 28 2000 - 16:03:17 EST


On Fri, 28 Jul 2000, Raj, Ashok wrote:

> Look at the khttp code, there is quite some examples in them.
>
> -----Original Message-----
> From: Vinay Vernekar [mailto:vinay.vernekar@wipro.com]
> Sent: Wednesday, July 26, 2000 3:16 AM
> To: linux-kernel@vger.rutgers.edu
> Subject: Reading a file inside the device driver.
>
>
> Hi,
> I am developing a network driver which has to read a file 'firmware.bin' and
> dump it into the modem memory. I want to know how can the file be opened and
> read inside a driver. As far as I know the normal file operation functions
> used in User applications like - fopen, fread can't be used in the driver
> code.
> Any suggestions on this is welcome.
> Thanks in advance.
>
> Regards
> Vinay
>

The easiest way, and the way which will always work in the future, is
to provide open() close() and ioctl() in your driver.

After the driver is installed (insmod) upon bootup, you execute a
user-mode program that opens the device and sends file-data to
the device via ioctl(). Your ioctl() routine in your driver
puts this stuff in the right place inside your hardware and
finishes initializing the device. The sysV-init scripts can
be modified to do this automatically. You could, of course do
the same thing using write(), but ioctl() allows you to pass
function parameters so your startup code might do something
like:
        fd = open("MyDevice", O_RDWR);
        file = open("MyBinaryJunk", O_RDONLY);
        ioctl(fd, MYDEV_WAKEUP);
        read(file, buf, len);
        ioctl(fd, MYDEV_UPLOAD_WINDOW0, buf);
        ioctl(fd, MYDEV_OPEN_WINDOW1);
        read(file, buf, len);
        ioctl(fd, MYDEV_UPLOAD_WINDOW1, buf);
        ioctl(fd, MYDEV_.... etc.
        ioctl(fd, MYDEV_START);

Another way, is to make a 'C' array of the data that you need
to put into your hardware. You can make a simple 'C' development
tool that reads data from your file, converts it to text the
compiler understands, and you include this during compilation.
This has at least two major problems. The first is that you have
to recompile to update your hardware-code. The second is that some
code may be very large. This stays within the kernel when the module
is installed and wastes kernel space.

You can't deallocate an array that the compiler initializes.

The last way, and the way I don't recommend, is to actually open
and read the file from kernel space. This is complex because your
driver needs to borrow a "process context" in order for file I/O
to work. The file-system was designed to run from a user's data
area (segment) and, for a file-descriptor to actually mean something,
it has to be associated with a process. This can be done and I am
sure that others will point you in that direction. However, what works
today might not work for the next kernel version.

I wrote such a driver about a year ago. It seemed to work after I
got a lot of help. However, even though the file was closed after
the read, I was never able to unmount '/'. This means the next boot
was a long fscking wait.

Ripping that up, and using user-mode access via ioctl() created a stable
driver with the minimum of resident code.

Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:28 EST