Hi, 2011/1/27 Akira Fujita <a-fujita@xxxxxxxxxxxxx>: > commit cc56f7de7f00d188c7c4da1e9861581853b9e92f made > sendfile(2) can work with any output file. > Therefore the out_fd of sendfile(2) can refer to any file, > but current manual (man-pages-3.32) has not been changed so far. And I thought I was the only one discovering it recently (beside a few obvious people year ago). :) > diff -Nrup man-pages-3.32-a/man2/sendfile.2 man-pages-3.32-b/man2/sendfile.2 > --- man-pages-3.32-a/man2/sendfile.2 Â Â2010-12-03 16:01:59.000000000 +0900 > +++ man-pages-3.32-b/man2/sendfile.2 Â Â2011-01-27 16:03:48.000000000 +0900 > @@ -87,15 +87,11 @@ and the file offset will be updated by t > Â.I count > Âis the number of bytes to copy between the file descriptors. > > -Presently (Linux 2.6.9): > -.IR in_fd , > +.IR in_fd > Âmust correspond to a file which supports > Â.BR mmap (2)-like > Âoperations > -(i.e., it cannot be a socket); > -and > -.I out_fd > -must refer to a socket. > +(i.e., it cannot be a socket). I don't think that completely removing out_fd socket restriction part is a proper way of fixing this page. Such information should not be lost. I would add here sth like: out_fd was required to be a socket, but since Linux 2.6.33 it can be any file. If it is a regular file, then sendfile() changes its offset appropriately. > > ÂApplications may wish to fall back to > Â.BR read (2)/ write (2) > @@ -168,6 +164,9 @@ In Linux 2.4 and earlier, > Âcould refer to a regular file, and s/could/could also/ > Â.BR sendfile () > Âchanged the current offset of that file. > +Since 2.6.33, > +.I out_fd > +can refer to any file. IMO this change shouldn't be mentioned in NOTES section. > > ÂThe original Linux > Â.BR sendfile () Regards. -- PrzemysÅaw 'Przemoc' PaweÅczyk http://przemoc.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
