Move POSIX network headers like <sys/socket.h> etc. to Newlib?

Sebastian Huber sebastian.huber at embedded-brains.de
Fri Apr 8 08:34:24 UTC 2016



On 08/04/16 04:22, Chris Johns wrote:
> On 8/04/2016 12:37 AM, Joel Sherrill wrote:
>>
>> Chris and I have discussed at least some of the network services being
>> considered packages beyond the stack. Stuff like httpd, ftpd, and
>> telnetd should be able to work with either stack. Having one instance of
>> those to maintain would be great.
>>
>> I'm happy to see all this happen. Hopefully it can show up in digestable
>> pieces.
>>
>
> We need to maintain our current functionality and I am prepared to 
> bridge but not abandon. The libbsd stack has made progress but does 
> not support as much as the old stack does. Until it does I feel we 
> need to keep the old stack going and to support it.

The old stack is still a valid option since it uses considerably less 
memory than the new stack.

>
> To me this means adding headers to newlib requires the in-tree stack 
> and libbsd work with out impacting users and existing applications.
>
> If I understand what is bring proposed any suitable networking 
> software should be able to be built against just the compiler, newlib 
> etc and it does not need a built and installed RTEMS with a specific 
> networking implementation. This means networking could become a link 
> time setting. An interesting challenge.

Yes, this is the goal.

>
> Sebastian, I know you have talked about libressl, but it is still not 
> clear to me why doing this is needed. Do you have a specific use case?

Its not needed, but would simplify things. We want to update the 
mongoose HTTP server to support HTTPS. We also want to use it with the 
old and new stack.

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




More information about the devel mailing list