Re: Accessing a file from kernel space

[Praveen Kumar <rptechie@xxxxxxxxx>]

Pharaoh . wrote:

On 2/6/07, Praveen Kumar <rptechie@xxxxxxxxx> wrote:

Pharaoh . wrote:

I am working on things which requires lot of data to be sent to the module continuously.
Yes, an aquisition system. The real work has not started yet, I was just trying to figure out
how to go about it.

I am not sure if what we are trying to do now will be of help to you. But it still comes under the broader "Accessing a file from kernel space" :-)

We are considering  two approaches for our work -
1. Follow the loop approach - Where the file is mapped into the memory & the IO is done. Please go through the loop device code, for more precise understanding.

If that is not what you are looking at then we are using a less optimal approach, which is but a TEMP HACK.
2. use the filp_open and stuff.

Personally I would not suggest 2nd approach, as we are facing glorious problems with it. So we are looking to change our design towards the 1st approach.
If you have any other ideas plz ping back bcoz even we are on a look out for optimized io to/fro file from kernel space.

Regards
Rp

On 2/2/07, Jon Masters <jonathan@xxxxxxxxxxxxxx> wrote:

Pharaoh . wrote:

> I know that this should be avoided as much as possibleI know this must
> have been discussed here many times before, and I know the various ways
> I can read a file from my module. But I am not very sure what is the
> best way to do so. Let me list out my approaches ranging from very crude
> to standard ones which we read in books.

> 3. Using sysfs.

It'd be best to know what you're trying to do. But generally, pushing to
the kernel from userspace (yeah, I know, twice the fun) is better than
even remotely thinking about using sys_* from in-kernel. Rule is:

* If you're using sys_<insert function here>, it's wrong.

But tell us more about what you're trying to do. Do you just need a
userspace library to parse some config data and shove it into the kernel
or do you need a high performance, high throughput data stream for some
highly reliable hardware acquisition system?

Jon.

>We are considering  two approaches for our work -
> 1. Follow the loop approach - Where the file is mapped into the memory & the IO is >done. Please go through the loop device code, for more precise understanding.

Praveen,

Can you explain the loop method in detail? Is this related to mapping the device memory in process address space i.e. mmap?

Pharaoh
Forewarning: Even I do not know much about this. As we are also trying to find more information about this approach. So what I am about to describe could be wrong or (hopefully) right. So please validate it.

I do not have a precise answer so I am going to explain what I did and what I understood. Please bear with this longer version of a definitely available precise answer.
>From my understanding of the working model loop device, the io happens at the physical page level. I mean, ofcourse, the pages are mapped into the virtual memory using kmap_atomic. And a simple memcpy is done to either retrieve or copy data to/fro these pages. But I was wondering how are they able to get the data from a file into a physical page. With a few search, I realized that a certain file_operation sendfile is used. And with further digging I realized that the field "f_mapping" in the struct file holds the key. This field apparently is the head of a radix tree of pages, which contains the data from the file!! Frankly after this, I am lost. I am lost as in when & how this radix tree is initialized and by whom. Will venture deeper into this a bit later; after my brain cells have cooled down. :-) Of course, I have some idea but I shall restrain until I confirm it.

Never the less, here is an un-tested yet-to-be-tried approach, I can suggest. After this mail, I am going to try this out in my work.So soon this will be tested.
The idea is to get the data from a file into a page. I am putting the logic in form of a pseudo-code for self-explanatory purpose.
 
struct page my_get_page_from_filename(pathname, offset)
{
            struct file *f = filp_open(pathname, O_RDWR, 0 );
            unsigned long index = offset >> PAGE_CACHE_SHIFT;          // convert into page granularity from byte granularity
            return find_get_page(f->f_mapping, index);
}

Of course, this above code is not complete & it is sans error checking and various other necessary things like page_cache_readahead and stuff. Anyways, calling the above function returns a physical page that contains the data from the given file @ the given offset. Now you can kmap this physical page into kernel virtual space for further io.
Hope this was clear. For any further clarity please go through loop.c, esp follow the elaborate step when the flow jumps from do_lo_receive() to lo_read_actor() though generic_file_sendfile(). On the other hand, you can go through the simpler code is do_lo_send(). But I prefer the do_lo_receive, as that gives a very very elaborate understanding of how to get the data from a file to a physical page.

Happy coding! :-)

Regards
Rp
-- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/