Sendfile for Rtems

[Gedare Bloom]

On Tue, Jun 23, 2015 at 3:13 PM, Sujay Raj <sujayraaj at 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.huber at 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 <eduardo at 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.sherrill at 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.sherrill at 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 at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel