I agree with Sebastian. Using read write in a loop can only serve as a makeshift measure.
If we have consensus here, then I can work on getting sendfile backed up in libbsd. (though, I have some serious background reading to do before I am able to do it, but I think I can. ) Thanks and Regards, Sujay Raj On Wed, Jun 24, 2015 at 12:21 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > I would use the sendfile system call implementation from FreeBSD and add > it to the libbsd. Its not a big win if you use read() and write() to > implement sendfile(). This makes only sense if you can use kernel space > zero-copy buffers. > > ----- Eduardo Silva <edua...@monkey.io> schrieb: > > > Sujay, > > Monkey use conditionals for each implementation: Linux, FreeBSD and OSX. > My suggestion is that RTEMS may implement a sendfile based on FreeBSD > format which can easily be emulated as a read() and further write() for > socket operations. That will help not only Monkey, but also other software > that requires such interface. > > I am not the best one to talk about RTEMS, but the Kernel always knows > better it buffers capacity that the program on the other side. > > do you think is possible to do that on RTEMS ? > > regards, > > On Tue, Jun 23, 2015 at 12:05 PM, Joel Sherrill <joel.sherr...@oarcorp.com > > wrote: > >> >> >> > >> >> > 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 >> >> > > > > > > -- > Eduardo Silva > Monkey Software > > > > > > -- > > Sebastian Huber, embedded brains GmbH > > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.huber at embedded-brains.de > <http://lists.rtems.org/mailman/listinfo/devel> > PGP : Public key available on request. > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
