Sendfile for Rtems

Tue Jun 23 19:19:03 UTC 2015

On 6/23/2015 2:15 PM, Gedare Bloom wrote:
> 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.

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.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

-- 
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