From owner-freebsd-net@freebsd.org Tue Apr 12 14:23:23 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B03CB0CE49 for ; Tue, 12 Apr 2016 14:23:23 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FD861ADD for ; Tue, 12 Apr 2016 14:23:23 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [IPv6:::1] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 2761575D4; Tue, 12 Apr 2016 16:23:20 +0200 (CEST) Subject: Re: libifconfig: Initial code available, looking for feedback Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Kristof Provost X-Checked-By-Nsa: Probably In-Reply-To: Date: Tue, 12 Apr 2016 16:23:16 +0200 Cc: freebsd-net@freebsd.org Message-Id: <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org> References: To: Marie Helene Kvello-Aune X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:23:23 -0000 > On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune = wrote: >=20 > > Expect the API to break frequently/often for the time being, as it = is still > > in very early stages of development. >=20 > I=E2=80=99ve had a quick look at the library so far, and have a few = remarks. >=20 > It might be better to have an explicit (opaque to the library user) = handle > to contain both the error state (libifconfig_errstate) and the open = sockets (sdkeys). > This would go a long way in making the library thread-safe (because = users can now > rely on their error state not getting clobbered by another thread). >=20 >=20 > Good idea. Adrian Chadd mentioned something like this off-list as = well, and I still haven't quite decided how to implement it. I have = considered looking into implementing this similar to how the global = 'errno' variable is implemented, but I haven't actually researched how = to do this yet. Iirc. errno is implemented using a thread-local variable. /usr/include/sys/errno.h #defines it to (* __error()), which is = implemented in lib/libc/sys/__error.c and lib/libthr/sys/thr_error.c That seems both complicated and needlessly restrictive. The second option gives all freedom to implementors. If they want one = libifc handle protected by a mutex that=E2=80=99s easy. If they want one = libifc handle per thread that=E2=80=99s also easy. >=20 > I'm currently leaning towards having a libifconfig_state_create() (or = similarily named) method which retrieves an appropriate struct for the = calling application to pass into the library methods. >=20 Yeah, I was thinking something along the lines of this: libifc_handle_t* libifc_open(); void libifc_close(libifc_handle_t *h); int libifc_set_mtu(libifc_handle_t *h, const char *name, int mtu); =E2=80=A6 Possibly also: int libifc_get_error(libifc_handle_t *h); If the definition of libifc_handle_t is kept opaque (so the headers only = have =E2=80=98struct libifc_handle; typedef struct libifc_handle = libifc_handle_t;=E2=80=99) you can get away with changing the size or = contents of the struct without breaking any of the users. (Because they=E2=80=99ll only have a pointer to keep track of, the size = of the object it points to doesn=E2=80=99t matter to them.) Regards, Kristof