On 6/23/2015 12:49 PM, Sujay Raj wrote:
I am working on porting Monkey HTTP server on rtems. Sendfile is not specified in POSIX.1-2001 or other standards and its implementations vary depending on the unix/linux system being used. Freebsd has sendfile in its libc.
FreeBSD has a completely different API for sendfile(). Plus the source must be a regular file and the destination a socket. https://www.freebsd.org/cgi/man.cgi?query=sendfile&sektion=2 This is a random discussion of sendfile() on various OSes. It mentions the assumption that the source must normally be able to be mmap'ed. Since you can't do that on RTEMS, you are stuck with a loop implementation. [1] https://groups.google.com/forum/#!topic/comp.unix.programmer/65oDSzpEzx8
So I opened this thread to discuss how should we proceed with this matter, if we should work on getting sendfile in newlib, or if there is any portable solution that we can use in its place.
Given that (a) it is not POSIX and (b) there is no agreement between Linux and FreeBSD, it is highly unlikely newlib would accept an implementation. Given (b), I don't personally see merging it into RTEMS since we have to pick a winner and loser on the API. What's the feeling on having a default implementation in Monkey and using that as a backup? With [1] as a consideration again. [1] The size of the buffer user for read/write has to be accounted for. If this is on a thread stack, then it can't be too large or that imposes a burden on calling sendfile(). I can see an implementation doing a malloc() of the buffer and then free()'ing it.
cc to Joel and Eduardo. Thanks and Regards, Sujay Raj
-- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
