From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Status update on 1.0 Date: Fri, 15 Mar 2019 14:31:31 -0400 Message-ID: References: <871s3a4xd4.fsf@gnu.org> <87zhpw2ql4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h4rcP-0001g9-Gp for guix-devel@gnu.org; Fri, 15 Mar 2019 14:31:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h4rcO-0000g2-Hh for guix-devel@gnu.org; Fri, 15 Mar 2019 14:31:45 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:37139) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h4rcO-0000fI-3q for guix-devel@gnu.org; Fri, 15 Mar 2019 14:31:44 -0400 Received: by mail-wr1-x42b.google.com with SMTP id y15so10606035wro.4 for ; Fri, 15 Mar 2019 11:31:43 -0700 (PDT) In-Reply-To: <87zhpw2ql4.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel On Fri, Mar 15, 2019 at 10:33 AM Ludovic Court=C3=A8s wrote: > > Hi, > > G=C3=A1bor Boskovits skribis: > > > Ludovic Court=C3=A8s ezt =C3=ADrta (id=C5=91pont: 2019. = m=C3=A1rc. 13., Sze, 16:21): > >> > >> Hello Guix! > > > >> =E2=80=A2 IPv6 support in =E2=80=98static-networking-service=E2=80= =99: as discussed at the > >> Guix Days, we=E2=80=99ll probably need to Linux Netlink sockets to= do that > >> rather than the old ioctls currently used in (guix build syscalls)= . > >> > >> The netlink interface for network config is vaguely documented at > >> . > >> Writing bindings for =E2=80=98sendmsg=E2=80=99 and the associated = data structures > >> looks reasonable=E2=80=A6 it just needs to be done. > >> > > > > I am interested in doing this. > > Awesome! > > > However, there are a few points that needs to be clarified: 1. I came > > to the same conclusion regarding the netlink stuff, but the old ioctl > > cannot be fully dropped. (It still provides funcions that are needed > > to get the netlink working) > > Yes, I think we can keep it. > > > 2. This might be linux specific. What do we do on other kernels? > > (It might be reasonable to provide the abstractions in a module, and > > from there select an available implementation, or signal an error that > > the functionality is not yet implemented for this system...) > > Wdyt? > > For now, we=E2=80=99ll have to ignore the other kernel. > > Longer-term, I suppose we should provide an abstraction over network > configuration and have it translated to Netlink messages or Hurd RPCs. > > > Also a nice low level binding written in C is available as libmnl: > > https://netfilter.org/projects/libmnl/index.html > > Or libnl also. Though if it=E2=80=99s not too hard, I=E2=80=99d rather h= ave us directly > bind to =E2=80=98sendmsg=E2=80=99, =E2=80=98struct msghdr=E2=80=99, and s= o on. Quick tangent: My memory is a bit fuzzy, but I think that netlink API wrappers would put us one step closer to being able to implement useful network isolation in our container implementation (right now you only have loopback, not so fun), like what Docker can do. Just something to consider. :) - Dave