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

[Sebastian Huber]

On 07/04/16 11:05, Chris Johns wrote:
> On 7/04/2016 4:45 PM, Sebastian Huber wrote:
>> Hello,
>>
>> what about moving the POSIX network headers
>>
>> arpa/inet.h
>> netdb.h
>> net/if.h
>> netinet/in.h
>> netinet/tcp.h
>> syslog.h
>> sys/socket.h
>> sys/uio.h
>> sys/un.h
>>
>> to Newlib?
>
> Where are these taken from?

 From the POSIX standard:

http://pubs.opengroup.org/onlinepubs/9699919799/
http://pubs.opengroup.org/onlinepubs/9699919799/idx/head.html

>
> Do they allow the in-tree stack to build? [1]

Probably not without modifications, but it is the goal. Before we start 
working on this we have to be sure that the general change is acceptable.

>
>>
>> This has the following benefits.
>>
>> 1. It ensures compatibility between the standard and libbsd network
>> stack at user API level.
>>
>
> Would this have to have a broader reach than just libbsd? What about 
> other parts of the networking software API a package may depend on? 
> How are those parts added onto this base level?
>
> For example I have an app which also includes ..
>
>  #include <net/if_types.h>
>  #include <net/if_dl.h>
>  #include <sys/sockio.h>

These header are not defined by POSIX. However, it probably makes sense 
to add the usual network headers as well.

>
> Would we support all these?
>
> Maybe looking at boosts source for asio would be worth doing.

Yes, but we do not plan to work on this.

>
>> 2. These files may be used by lwIP to provide the standard API.
>
> Is this something to be added to lwIP or this is there now?

As far as I know lwIP doesn't provide the standard headers. They must be 
supplied externally.

>
>> 3. It allows 3rd party code depending only on the POSIX network headers
>> to build without RTEMS, e.g. GCC Ada and Go languages, libressl library
>> etc. Allows build of libraries per multilib.
>
> Does this mean networking is always shown to be present even if the 
> user does not want to enable networking functionality in a 3rd party 
> package?

Yes, in case it only checks the header files.

>
> If this helps us remove the in-tree stack from the source tree I am 
> all for it.
>
> Would this allow the existing NSF client to build with the new stack?

I don't think so, due to the dependency on the RPC support (which is a 
real hack and a ticking security bomb).

>
> In general I think this is a good idea, however I do see some detail 
> we need to sort out. Thanks for raising this.
>
> Chris

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