Re: splice() and file offsets

[Jens Axboe]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/