From: Jonathan Lundell <jlundell@pobox.com>
To: Sandip Bhattacharya <sandip@webyarn.com>, linux-kernel@vger.kernel.org
Subject: Re: procfs feature or bug?
Date: Wed, 19 Sep 2001 09:19:25 -0700 [thread overview]
Message-ID: <p05100307b7ce752abd7c@[207.213.214.37]> (raw)
In-Reply-To: <20010919155332.A980@mindsw.com>
In-Reply-To: <20010919155332.A980@mindsw.com>
At 3:53 PM +0530 2001-09-19, Sandip Bhattacharya wrote:
>I was trying out the multipage procfs entries, when i found out that i
>was having a problem.
>
>I am trying to use the "hack" by Paul Russell to allow mangling of
>filepos using ``*start'' entries as my personal page offset. Now, for
>multipage entries, whatever i set as *start should be coming back to
>me as offset when the next page is called.
>
>But in fs/proc/generic.c in proc_file_read() at the end we have (
>after the first page has been "copied_to_user")
>
> *ppos += start < page ? (long) start : n;
>
>But this _adds_ the contents of start to the offset, in the case where
>I am supplying the offset in ``start''. Shouldn't this just be
>_replacing_ ? 'Cause in this case the offsets get cumulatively added,
>causing an oops at the end for me :(
>
>Or am I missing something big???
Per the comment:
> /* This is a hack to allow mangling of file pos independent
> * of actual bytes read. Simply place the data at page,
> * return the bytes, and set `start' to the desired offset
> * as an unsigned int. - Paul.Russell@rustcorp.com.au
> */
*ppos represents the offset in the *file*, not the buffer, so
cumulative is correct. So when you do your read, you need to
interpret it thus. I've been using it in one case as a record number,
where the records are variable length. I set *start to 1, and treat
is as an index into a (virtual) array of records.
--
/Jonathan Lundell.
prev parent reply other threads:[~2001-09-19 16:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-19 10:23 Sandip Bhattacharya
2001-09-19 16:19 ` Jonathan Lundell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='p05100307b7ce752abd7c@[207.213.214.37]' \
--to=jlundell@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sandip@webyarn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®