In short:
The hack used to be able to read proc files larger than 4k, breaks if the
caller does lseek() after read()
Detailed:
I am providing a proc read interface to one of my proc files by using the
given hack symantics in which every call to read_proc() writes the data
starting at the begining of the page but sets "*start" artificially to
indicate how many fields have been read. proc_file_read then correctly
adjusts *ppos to signify the artificial position inside the proc file
where the read pointer points. It is *artificial* beacuse it is not the
byte offset but some other offset which only read_proc understands. Next
time around when read_proc gets the *ppos to start reading from it knows
how to calculate the exxat byte offset from the *artificial* *ppos
provided.
This works fine with cat which simply calls read(). The "more" command
though has the following call pattern
read(fd,buf,4096) = X
lseek(fd,X,SEEK_SET);
-- lseek modified file->f_pos to the byte offset value, which disturbed
read_proc ---
read(fd,buf,4096) = 0;
the effect is that more never gives me data more than 4096 bytes worth.
My Question is. Is it a known problem ?
Thanx
tomar
On Thu, 7 Aug 2003, Nagendra Singh Tomar wrote:
> In short:
> The hack used to be able to read proc files larger than 4k, breaks if the
> caller does lseek() after read()
>
> Detailed:
> I am providing a proc read interface to one of my proc files by using the
> given hack symantics in which every call to read_proc() writes the data
> starting at the begining of the page but sets "*start" artificially to
> indicate how many fields have been read. proc_file_read then correctly
> adjusts *ppos to signify the artificial position inside the proc file
> where the read pointer points. It is *artificial* beacuse it is not the
> byte offset but some other offset which only read_proc understands. Next
> time around when read_proc gets the *ppos to start reading from it knows
> how to calculate the exxat byte offset from the *artificial* *ppos
> provided.
> This works fine with cat which simply calls read(). The "more" command
> though has the following call pattern
>
> read(fd,buf,4096) = X
> lseek(fd,X,SEEK_SET);
>
> -- lseek modified file->f_pos to the byte offset value, which disturbed
> read_proc ---
>
> read(fd,buf,4096) = 0;
>
>
> the effect is that more never gives me data more than 4096 bytes worth.
>
> My Question is. Is it a known problem ?
Yep known issue, i need to get around to look and test the patch.
http://bugzilla.kernel.org/show_bug.cgi?id=952
--
function.linuxpower.ca
On Fri, 8 Aug 2003, Zwane Mwaikambo wrote:
> On Thu, 7 Aug 2003, Nagendra Singh Tomar wrote:
>
> > In short:
> > The hack used to be able to read proc files larger than 4k, breaks if the
> > caller does lseek() after read()
> >
> > My Question is. Is it a known problem ?
>
> Yep known issue, i need to get around to look and test the patch.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=952
Sorry ignore that, i should get some sleep.
--
function.linuxpower.ca
In message <[email protected]> you write:
> In short:
> The hack used to be able to read proc files larger than 4k, breaks if the
> caller does lseek() after read()
Hmm, my more(1) does this too. What a PITA. less(1) does not.
I've never noticed it before, though. I certainly didn't notice it
when I implemented the hack.
Of course, converting to seq_file is probably the nicest solution
these days.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.