On Tue, Jun 23, 2015 at 3:13 PM, Sujay Raj <sujayr...@gmail.com> wrote: > 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. ) > Yes this makes the most sense.
> 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 >> 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
