On 6/23/2015 2:15 PM, Gedare Bloom wrote:
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.
If it doesn't rely on mmap(). If it does, then it won't work.
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
--
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
