"A month of sundays ago Mike Galbraith wrote:"
> On Sun, 13 Feb 2000, Mike Galbraith wrote:
>
> > On Sun, 13 Feb 2000, Peter T. Breuer wrote:
> >
> > > Could someone kindly point me to an example in the source to show me
> > > jow to get more than a page out of a proc file on read?
> >
> > No, but IKD has memleak and ktracer which do.
>
> Hmm.. otoh, maybe I misunderstood (just thought about kcore). Are you
> maybe having trouble with truncated data? I had this trouble with ikd,
> and did the below.
I was (first of all) trying to use the standard read function that one
registers with a proc entry in the ordinary way. It has enough params
that I guess they are intended to be able to convey the idea back and
forth between caller and callee that we are on a new page or in a
different place on the same page. Tracing shows that a single cat of
the proc entry causes these calls to the function I registered with
the proc entry:
int get_proc_config(char *page, char **start, off_t offset, int len, int
unused);
get_proc_config called with page c162c000, start 0, offset 0, len 3072
get_proc_config returned 3071 bytes to c162c000
get_proc_config called with page c1502000, start 0, offset 3071, len 3072
get_proc_config returned 2248 bytes to c1502000
That is, a total of 5319 bytes were returned on two different pages. It
can happen that the function is called twice in succession with the
same page as target, which I detect, and I offset the data returned
correctly for that situation (yecch, race between two reading
processes?).
Nevertheless, the process reading the data off proc with cat only got
3071 bytes, measured by the process. This is itself a success. Here's
a case when it gets those bytes in dribbles:
get_proc_config called with page c2bcd000, start 0, offset 0, len 1024
get_proc_config returned 1009 bytes to c2bcd000
get_proc_config called with page c2bcd000, start 0, offset 1009, len 1024
get_proc_config returned 1017 bytes to c2bcd3f1
get_proc_config called with page c3630000, start 0, offset 1017, len 1024
get_proc_config returned 1021 bytes to c3630000
get_proc_config called with page c3630000, start 0, offset 1021, len 1024
get_proc_config returned 1024 bytes to c36303fd
get_proc_config called with page c3630000, start 0, offset 1024, len 1021
get_proc_config returned 1010 bytes to c36307fd
get_proc_config called with page c3630000, start 0, offset 1024, len 1024
get_proc_config returned 238 bytes to c3630bfd
(I am using cat, not dd). As you can see, it looks like the call
is made with offset equal to the required _incremental_ offset since
last time, whether we're on the same page or not. Usually the
offset in the next call is equal to the number of bytes we delivered
last time. And sometimes the new offset in the next call doesn't
quite correspond to what we delivered last. Above, an offset of
1024 is passed when we reported 1010 bytes last time.
And the *start value (which is shown) doesn't change, so I guess it
needs help.
> diff -urN linux-2.3.44.virgin/fs/proc/generic.c linux-2.3.44.test/fs/proc/generic.c
> --- linux-2.3.44.virgin/fs/proc/generic.c Fri Feb 11 14:32:40 2000
> +++ linux-2.3.44.ikd/fs/proc/generic.c Fri Feb 11 12:50:39 2000
> @@ -106,6 +106,11 @@
> * return the bytes, and set `start' to the desired offset
> * as an unsigned int. - Paul.Russell@rustcorp.com.au
> */
> + /* Ensure that the data will fit when using the ppos hack,
> + * otherwise userland receives truncated data.
> + */
> + if (n > count-1 && start && start < page)
> + break;
What ppos hack? Am I supposed to return the bytes to the beginning
of the page each time, and set *start to the offset where I calculate
it should start? In that case, will the offsets passed down star being
right :-)?
> n -= copy_to_user(buf, start < page ? page : start, n);
> if (n == 0) {
> if (retval == 0)
>
Thanks!
Peter
-
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 : Tue Feb 15 2000 - 21:00:24 EST