On Tue, Apr 12, 2016 at 4:23 PM Kristof Provost <k...@freebsd.org> wrote:
> On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune < > mariehelen...@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’ve had a quick look at the library so far, and have a few remarks. >> >> 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). >> >> > 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’s easy. If they want one libifc > handle per thread that’s 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); > … > > 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 ‘struct libifc_handle; typedef struct libifc_handle libifc_handle_t;’) > you can get away with changing the size or contents of the struct without > breaking any of the users. > (Because they’ll only have a pointer to keep track of, the size of the > object it points to doesn’t 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 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
