On Mon, Jul 10 2006, Michael Kerrisk wrote:
> Jens,
>
> > > Yes, I understand what the code is doing, but *why* do
> > > things this way? (To put things another way: why not *always
> > > have splice() update the file offset?) I realise there may be
> > > some good reason for this, and if there is, it will go into the
> > > man page!
> >
> > The good reason is why update the current position? I just told the
> > kernel to ignore the current position and use the given offset, why
> > would I bother updating the current position? The whole point of
> > providing an offset is to ignore the current position.
> >
> > I must say I cannot understand why you are confused or find this
> > illogical, it makes perfect sense to me.
>
> Yes, now it's clear to me too.
>
> [...]
>
> > > No! It does not! See the sendfile.2 man page: "sendfile()
> > > does not modify the current file offset of in_fd."
> >
> > I didn't read the man page, I read the source. And it clearly updates
> > the file offset, in fact the actual sendfile portion is just a supplied
> > actor to the generic page cache read functions.
>
> Doh! I took what I "knew", re-read the sendfile.2 manual page to
> check, misread the source, and then wrote an inadequate
> test program :-{. (The sendfile manual page is now fixed.)
>
> > If you don't believe me, read the source and do another test app.
> > splice() behaves identically, as previously stated.
>
> Now I believe you; sorry to have wasted your time...
No worries, glad we got it sorted out :-)
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
