libifconfig: Initial code available, looking for feedback

[Kristof Provost]

> On 12 Apr 2016, at 16:09, Marie Helene Kvello-Aune <marieheleneka at 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