Re: [PATCH] LwIP translator

[James Clarke]

Hi Joan,

On 24 Aug 2017, at 18:49, Joan Lledó  wrote:
> ...
> diff --git a/config.make.in b/config.make.in
> index dfbf0c1..f74220e 100644
> --- a/config.make.in
> +++ b/config.make.in
> @@ -99,6 +99,13 @@ HAVE_SUN_RPC = @HAVE_SUN_RPC@
> # Whether we found libgcrypt.
> HAVE_LIBGCRYPT = @HAVE_LIBGCRYPT@
> 
> +# Whether we found libgcrypt.

Copy-paste error :)

James

[PATCH] LwIP translator

[Joan Lledó]

---
 Makefile |   4 +
 config.make.in   |   7 +
 configure.ac |   5 +
 lwip/Makefile|  51 +++
 lwip/config.h|   5 +
 lwip/iioctl-ops.c| 418 
 lwip/io-ops.c| 560 ++
 lwip/lwip-hurd.h | 100 +
 lwip/lwip-util.c | 348 +
 lwip/lwip-util.h |  41 ++
 lwip/main.c  | 234 +++
 lwip/mig-decls.h |  68 
 lwip/mig-mutate.h|  44 +++
 lwip/options.c   | 346 +
 lwip/options.h   |  81 
 lwip/pfinet-ops.c| 119 ++
 lwip/port-objs.c | 143 +++
 lwip/port/include/netif/hurdethif.h  |  39 ++
 lwip/port/include/netif/hurdloopif.h |  36 ++
 lwip/port/include/netif/hurdtunif.h  |  65 
 lwip/port/include/netif/ifcommon.h   |  60 +++
 lwip/port/netif/hurdethif.c  | 688 
 lwip/port/netif/hurdloopif.c | 112 ++
 lwip/port/netif/hurdtunif.c  | 734 +++
 lwip/port/netif/ifcommon.c   | 121 ++
 lwip/socket-ops.c| 458 ++
 26 files changed, 4887 insertions(+)
 create mode 100644 lwip/Makefile
 create mode 100644 lwip/config.h
 create mode 100644 lwip/iioctl-ops.c
 create mode 100644 lwip/io-ops.c
 create mode 100644 lwip/lwip-hurd.h
 create mode 100644 lwip/lwip-util.c
 create mode 100644 lwip/lwip-util.h
 create mode 100644 lwip/main.c
 create mode 100644 lwip/mig-decls.h
 create mode 100644 lwip/mig-mutate.h
 create mode 100644 lwip/options.c
 create mode 100644 lwip/options.h
 create mode 100644 lwip/pfinet-ops.c
 create mode 100644 lwip/port-objs.c
 create mode 100644 lwip/port/include/netif/hurdethif.h
 create mode 100644 lwip/port/include/netif/hurdloopif.h
 create mode 100644 lwip/port/include/netif/hurdtunif.h
 create mode 100644 lwip/port/include/netif/ifcommon.h
 create mode 100644 lwip/port/netif/hurdethif.c
 create mode 100644 lwip/port/netif/hurdloopif.c
 create mode 100644 lwip/port/netif/hurdtunif.c
 create mode 100644 lwip/port/netif/ifcommon.c
 create mode 100644 lwip/socket-ops.c

diff --git a/Makefile b/Makefile
index 119f130..2d9d3f8 100644
--- a/Makefile
+++ b/Makefile
@@ -50,6 +50,10 @@ ifeq ($(HAVE_SUN_RPC),yes)
 prog-subdirs += nfs nfsd
 endif
 
+ifeq ($(HAVE_LIBLWIP),yes)
+prog-subdirs += lwip
+endif
+
 # Other directories
 other-subdirs = hurd doc config release include
 
diff --git a/config.make.in b/config.make.in
index dfbf0c1..f74220e 100644
--- a/config.make.in
+++ b/config.make.in
@@ -99,6 +99,13 @@ HAVE_SUN_RPC = @HAVE_SUN_RPC@
 # Whether we found libgcrypt.
 HAVE_LIBGCRYPT = @HAVE_LIBGCRYPT@
 
+# Whether we found libgcrypt.
+HAVE_LIBLWIP = @HAVE_LIBLWIP@
+
+# How to compile and link against liblwip.
+liblwip_CFLAGS = @liblwip_CFLAGS@
+liblwip_LIBS = @liblwip_LIBS@
+
 # Installation tools.
 INSTALL = @INSTALL@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
diff --git a/configure.ac b/configure.ac
index 54aa72b..5abedf4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -344,6 +344,11 @@ AC_SUBST([libblkid_CFLAGS])
 AM_PATH_LIBGCRYPT("1:1.6.0",[HAVE_LIBGCRYPT=yes], [HAVE_LIBGCRYPT=no])
 AC_SUBST([HAVE_LIBGCRYPT])
 
+PKG_CHECK_MODULES([liblwip], [lwip], [HAVE_LIBLWIP=yes], [HAVE_LIBLWIP=no])
+AC_SUBST([HAVE_LIBLWIP])
+AC_SUBST([liblwip_CFLAGS])
+AC_SUBST([liblwip_LIBS])
+
 AC_CONFIG_FILES([config.make ${makefiles}])
 AC_OUTPUT
 
diff --git a/lwip/Makefile b/lwip/Makefile
new file mode 100644
index 000..e9289b5
--- /dev/null
+++ b/lwip/Makefile
@@ -0,0 +1,51 @@
+#   Copyright (C) 2017 Free Software Foundation, Inc.
+#
+#   This file is part of the GNU Hurd.
+#
+#   The GNU Hurd is free software; you can redistribute it and/or
+#   modify it under the terms of the GNU General Public License as
+#   published by the Free Software Foundation; either version 2, or (at
+#   your option) any later version.
+#
+#   The GNU Hurd is distributed in the hope that it will be useful, but
+#   WITHOUT ANY WARRANTY; without even the implied warranty of
+#   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#   General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with the GNU Hurd.  If not, see .
+
+dir= lwip
+makemode   = server
+
+PORTDIR = $(srcdir)/port
+
+SRCS   = main.c io-ops.c socket-ops.c pfinet-ops.c iioctl-ops.c 
port-objs.c \
+   options.c lwip-util.c
+IFSRCS = ifcommon.c hurdethif.c hurdloopif.c hurdtunif.c
+MIGSRCS= ioServer.c socketServer.c pfinetServer.c 
iioctlServer.c
+OBJS   = $(patsubst %.S,%.o,$(patsubst 

[PATCH] LwIP translator

[Joan Lledó]

I made some changes to conditionally build the lwip translator depending on
whether liblwip is installed.

Re: [GSoC 2017] Number fo sockets

[Mark H Weaver]

Hi,

Joan Lledó  writes:

> As I mentioned in my previous post about ioctl operations[1], LwIP
> establishes a maximum limit of sockets, which is a big problem for a
> system like the Hurd. Now I've finished all tasks in my initial
> proposal, I thought it was a good idea to spend some time studying
> this issue and trying to find a solution.
>
> The problem is this: in LwIP, sockets are stored in a fixed-size
> array, which is the best solution for embedded systems as it is a
> natural way of indexing items without need of additional variables and
> allows the user to directly access any socket from its index taking
> the same time. If we remove the limited amount of sockets, then we
> cannot keep using an array, and another solution is required to handle
> all this.
>
> In the LwIP translator, I've chosen to replace the array for a linked
> list, and that has some implications: the need to iterate the list any
> time we need to create, destroy or look for a particular socket,

I would be good to avoid having socket lookup require time proportional
to the number of sockets.  The number of sockets may grow quite large in
some applications.

Instead of a linked list, how about using a dynamic array?

  https://en.wikipedia.org/wiki/Dynamic_array

This would give you constant-time lookups, amortized constant time
insertions and deletions, and better data locality and cache behavior.

What do you think?

  Mark