Date: Sat, 16 Apr 2016 02:08:36 +0000 From: Marie Helene Kvello-Aune <marieheleneka@gmail.com> To: Kristof Provost <kp@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: libifconfig: Initial code available, looking for feedback Message-ID: <CALXRTbeQY-HMV_UeVBeKwrE-3mq_znbYAP6P9YLHqgpCm3ZFhQ@mail.gmail.com> In-Reply-To: <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org> References: <CALXRTbfxxf%2BbUev8sBoJEOfR41ZsLnB35i%2B4G_2Bp=j-eVVJQQ@mail.gmail.com> <C6D42B75-5C78-45F1-8AFD-3CD8D2BF2E1D@FreeBSD.org> <CALXRTbe14nzRt15P_Tn4tUsgDPmEwJ_bHHVMMakzHfas2OYdWg@mail.gmail.com> <24C6C827-DD53-447B-B9EB-90E73347DC1A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 12, 2016 at 4:23 PM Kristof Provost <kp@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALXRTbeQY-HMV_UeVBeKwrE-3mq_znbYAP6P9YLHqgpCm3ZFhQ>