Sendfile for Rtems
Sujay Raj
sujayraaj at gmail.com
Tue Jun 23 19:32:32 UTC 2015
Okay, So I will dig in to the details of the implementation of sendfile on
freebsd to find if it does indeed use mmap, or if there is an
implementation that doesn't.
I will inform as soon as I figure it out if this is the correct way out.
Thanks and Regards,
Sujay Raj
On Wed, Jun 24, 2015 at 12:49 AM, Joel Sherrill <joel.sherrill at oarcorp.com>
wrote:
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150624/ebd7fb24/attachment-0002.html>
More information about the devel
mailing list