On 11/18/06, Bithika Khargharia <bithika@xxxxxxxxx
> wrote:
You are absolutely right :)
The catch is that the m->buf pointer is always zero-ed inside seq_open().
And therefore, the first call to the seq_read() executes the above code.
This is indeed very strange. What tells you that the size goes up to 16*PAGE_SIZE?
I think that you might have a look at the relayfs:
http://relayfs.sourceforge.net/
".. Basically relayfs is just a bunch of per-cpu kernel buffers that can be efficiently written into from kernel code. These buffers are represented as files which can be mmap'ed and directly read from in user space. The purpose of this setup is to provide the simplest possible mechanism allowing potentially large amounts of data to be logged in the kernel and 'relayed' to user space .."
Hope that helps :)
BlackHole
buf gets set to PAGE_SIZE size in the the seq_read() only if m->buf is NULL. Am I right?
You are absolutely right :)
if (!m->buf) {
m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);
if (!m->buf)
goto Enomem;
}
But I malloc'ked m->buf before when the seq_file m is first opened in zoneinfo_open()
The catch is that the m->buf pointer is always zero-ed inside seq_open().
And therefore, the first call to the seq_read() executes the above code.
Also, I noticed a very strange behavior with setting the PAGE_SIZE for seq_file. Unless, I read any data into the seq_file the seq_file size always remains PAGE_SIZE, but as soon as I read a big amount of data the seq_file size actually goes upto 16*PAGE_SIZE. I don't know where that came from. I only set it to 2*PAGE_SIZE.
This is indeed very strange. What tells you that the size goes up to 16*PAGE_SIZE?
However, it served my purpose (or least it appears to have) because I am basically trying to read a huge portion of the lru active list (for all ZONES) into the seq_file
Is there a better way of doing this?
I think that you might have a look at the relayfs:
http://relayfs.sourceforge.net/
".. Basically relayfs is just a bunch of per-cpu kernel buffers that can be efficiently written into from kernel code. These buffers are represented as files which can be mmap'ed and directly read from in user space. The purpose of this setup is to provide the simplest possible mechanism allowing potentially large amounts of data to be logged in the kernel and 'relayed' to user space .."
Hope that helps :)
BlackHole