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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
