Messages in this thread | | | Subject | Re: proc_file_read bug? | From | Andreas Schwab <> | Date | Fri, 25 Jan 2002 15:29:35 +0100 |
| |
Thomas Hood <jdthood@mail.com> writes:
|> I don't understand this part of proc_file_read() in |> fs/proc/generic.c: |> |> /* 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 |> */ |> n -= copy_to_user(buf, start < page ? page : start, n); |> if (n == 0) { |> if (retval == 0) |> retval = -EFAULT; |> break; |> } |> |> *ppos += start < page ? (long)start : n; /* Move down the file */ |> nbytes -= n; |> buf += n; |> retval += n; |> |> When start >= page, we copy n bytes beginning at start and |> increase *ppos by n. Makes sense. But what happens when |> start < page? We will copy n bytes starting at page, then |> increase *ppos by start!! What sense does that make? If |> there's cleverness happening here, someone please document it.
It is documented, RTFC.
Andreas.
-- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |