From owner-freebsd-net@freebsd.org Sat Apr 16 02:08:49 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 BA75FAED03B for ; Sat, 16 Apr 2016 02:08:49 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33A13130F; Sat, 16 Apr 2016 02:08:49 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-lf0-x231.google.com with SMTP id g184so164248166lfb.3; Fri, 15 Apr 2016 19:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nB3hne9MQkRWAZkA/6m/PPe3NKiQF2fZQoxfE4+owT4=; b=M2+sWTosPwARK1OFZt9GFsuhGVxG4fmij15n55VqrrMEUjyh0pax3TyyZ8bIHBq72s bLjCfWXqsnwH+L21CQ8nJ0Dxcom812EIUVHxjN7H8d3jtrSgi9n3eQq65zm/INzEuJ+g aAy1j5hzHI1ymvkeaAD3XL/03TH8VXhQE9huh39ubpvegJxBTOU80AAwl6g14jHeEozx cORfipvjMrulAR9C4GxqeqVtxR/hbZ7SP3HYGMKTFe3i+nGatoyMospS9mSR3WDfeCle Ih8osbJEhH224NH7GuuHFUpFlRC/tXGJfgapTuEAFHv39VvuqWVn1QvzH88waoBsnnm1 uZ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nB3hne9MQkRWAZkA/6m/PPe3NKiQF2fZQoxfE4+owT4=; b=YeO3FcPR3kGR2nlg0nVOo6wn/ANTPEzEzaU0++z2m86WA52KRF/QKRaM4Id4bjroX4 xrfU6i6ZUVrfA9H8Q341X5SVZZKwQvECJbAA+lyqx1AeKWDNc51LA2bAEBLtv61o5XcD MtopkD0RVQ1UcgWfG2xAAGdJKMdRNrAIdbjzYv8R7HnjBKW0dgCl7KHeQMvm0S62mSbT PdASjqR2gkw8ZGYiOmyE4ikcRpiiCt2n6deKebRD9b+hLHruTpH3NNlQnSF/wnbrMMVt iL0HWGd8ng+8pXko/BQJHvaExhOjp1rJ5WM4H3fghNSoi0Paa1Gq1+T08EhDqtHPYg87 Id7w== X-Gm-Message-State: AOPr4FWdsOKNe7e+EeTZVXDBtnHdx2xX2/sozvOMNkgSAXk+0Wrg1Bp/t9A4XDEygSqaeP8Fj+iSO2IVbvqJng== X-Received: by 10.25.85.210 with SMTP id j201mr8774731lfb.132.1460772526343; Fri, 15 Apr 2016 19:08:46 -0700 (PDT) MIME-Version: 1.0 References: <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org> In-Reply-To: <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org> From: Marie Helene Kvello-Aune Date: Sat, 16 Apr 2016 02:08:36 +0000 Message-ID: Subject: Re: libifconfig: Initial code available, looking for feedback To: Kristof Provost Cc: freebsd-net@freebsd.org 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: Sat, 16 Apr 2016 02:08:49 -0000 On Tue, Apr 12, 2016 at 4:23 PM Kristof Provost wrote: > On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune < > marieheleneka@gmail.com> wrote: > >> >> > Expect the API to break frequently/often for the time being, as it is >> still >> > in very early stages of development. >> >> I=E2=80=99ve had a quick look at the library so far, and have a few rema= rks. >> >> It might be better to have an explicit (opaque to the library user) hand= le >> 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 user= s >> can now >> rely on their error state not getting clobbered by another thread). >> >> > 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. > > > 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. > > 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_h= andle_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 o= f the > object it points to doesn=E2=80=99t matter to them.) > > Regards, > Kristof > > Thanks for the feedback. The past couple of days, I've committed these changes to the API. The repo[1] have examples describing how to use libifconfig, updated to the new API structure. In short, the prefix is now libifc_ instead of libifconfig_, every method require a libifc_handle_t as first argument, and there are three methods to retrieve error state (libifc_err_errtype(handle), libifc_err_errno(handle), libifc_err_ioctlreq(handle)) I'll be working on reducing boilerplate code within the API implementation itself today, then start adding more features. [1] https://github.com/Savagedlight/libifconfig Regards, Marie Helene