Re: Provide POSIX network header for all normal Newlib targets?

[Corinna Vinschen <vinschen at redhat dot com>]

Hi Sebastian,

On Apr 21 12:12, Sebastian Huber wrote:
> Hello,
> 
> with the recent type changes for <sys/types.h> etc. we are now able to build
> the FreeBSD 9.3 network stack on RTEMS. We directly use
> 
>  * <machine/endian.h>,
>  * <sys/_stdint.h>,
>  * <sys/time.h>,
>  * <sys/_timespec.h>,
>  * <sys/_timeval.h>,
>  * <sys/_types.h>, and
>  * <sys/types.h>
> 
> from Newlib with mostly unmodified FreeBSD header and source files.
> 
> Cygwin and Linux provide currently their own set of network header files in
> Newlib. RTEMS has its own sets outside of Newlib. Since the Linux port is a
> bit special I don't consider it here. I think for the other Newlib targets
> it may be beneficial to provide at least the POSIX network header files
> 
>  * <arpa/inet.h>,
>  * <netdb.h>,
>  * <net/if.h>,
>  * <netinet/in.h>,
>  * <netinet/tcp.h>,
>  * <syslog.h>,
>  * <sys/socket.h>,
>  * <sys/uio.h>, and
>  * <sys/un.h>
> 
> in Newlib. It has the advantage that Newlib users get a consistent set of
> POSIX network header files with compatibility to FreeBSD. Since there are a
> lot of software packages available for Cygwin it would be quite nice for the
> smaller embedded systems targets to share header files with Cygwin.
> 
> My approach would be to import the latest network header files from FreeBSD.
> Then remove all #ifdef _KERNEL parts and use an #include <machine/XZY.h> to
> provide machine-specific stuff for each header file, e.g.
> <machine/socket.h>, <machine/in.h>. Keep the #ifndef _KERNEL parts for
> FreeBSD compatibility.
> 
> I only roughly looked at the Cygwin network headers, but it would be a bit
> of work to import the latest network headers from FreeBSD and use them in
> Cygwin, e.g. deal with __INSIDE_CYGWIN_NET__.
> 
> How do you think about this?

Nice idea in general.   For Cygwin there are two complications:

- Building Cygwin itself (what __INSIDE_CYGWIN_NET__ is supposed to
  handle) is about building Cygwin network internals.  The problem here
  is that Cygwin's network code is a bastard.  Under the hood it has to
  use Winsock functions, while on top it provides the POSIX stuff, and
  they don't agree on everything.  Usually the definitions in our header
  files use their Winsock values to avoid having to map values between
  multiple sets.

  However, the usage of __INSIDE_CYGWIN_NET__ in our headers isn't always
  correct.  It covers much more functions and definitions than available
  in native Windows.   There may be dragons...

- The usage of

    #if !(defined  (_WINSOCK_H) || defined (_WINSOCKAPI_) \
          || defined (__USE_W32_SOCKETS))

  in some newlib headers is supposed to allow creating a Cygwin
  executable which uses the Winsock socket functions instead of the
  Cygwin POSIX socket functions.  That's only marginally supported but
  IIRC it's also needed right now to build Cygwin's socket code.

  I'm inclined to drop support for building against Winsock entirely and
  for the Cygwin build itself the above could be replaced with
  __INSIDE_CYGWIN_NET__.  However, if it's not in the way of what you're
  planning, we can just keep it as is for now.

Other than that, I'm on vacation for a while now.  You might want to
wait with this stuff until I'm back.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature