I think RelayFs is the thing. See http://relayfs.sourceforge.net/.
On 2/6/07, Praveen Kumar <rptechie@xxxxxxxxx> wrote:
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/
--
Regards,
Sandeep.
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
