libifconfig: Initial code available, looking for feedback

[Marie Helene Kvello-Aune]

On Mon, Apr 11, 2016 at 10:31 PM Kristof Provost <kp at freebsd.org> wrote:

>
> > On 09 Apr 2016, at 15:59, Marie Helene Kvello-Aune <
> marieheleneka at gmail.com> wrote:
> > I've just pushed an initial version of libifconfig to the github
> > repository[2]. I would appreciate feedback, in particular on the API
> design
> > and usage, and especially on how it communicates error state to the
> > application.
> >
> Awesome. This is important work. I can’t be the only one who’s tired of
> writing
> ioctl() calls to set an IP address.
>
> Is it still your intention to re-implement/refactor/re-whatever ifconfig
> to use this
> library? It seems like it’d be both a good test-case and a good way to
> ensure
> the library stays up to date, and grows new capabilities as features are
> added
> to the network stack.


I'm actually converting ifconfig as I add features to the library. It's how
I test that things seem to work. :)


>
> > 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.

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.

Both approaches should be thread friendly.


> Bikeshedding:
>  - libifconfig_ seems quite long for a prefix. Perhaps libifc_ or lifc_ ?
>  - if (foo != NULL) free(foo); can be safely written as free(foo);
>
>
Yeah, I have been feeling the prefix is a bit long as well. libifc_ looks
ok to me.



> Regards,
> Kristof


Thanks for the feedback!

Regards,
Marie Helene Kvello-Aune
marieheleneka at gmail.com