Date: Fri, 4 Mar 2016 08:20:19 -0700 From: Alan Somers <asomers@freebsd.org> To: Marie Helene Kvello-Aune <marieheleneka@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: libifconfig: A C API for ifconfig Message-ID: <CAOtMX2i0UE4jAfkZspFrs3Zx12-Pf4%2Bqu2Tp3aL8JcVamZd0uw@mail.gmail.com> In-Reply-To: <CALXRTbdH__wM_g2Qmt17tobBXAjnamkTKcs28qRo0qy9_OOjUg@mail.gmail.com> References: <CALXRTbdH__wM_g2Qmt17tobBXAjnamkTKcs28qRo0qy9_OOjUg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 4, 2016 at 8:10 AM, Marie Helene Kvello-Aune < marieheleneka@gmail.com> wrote: > Hey! > > I'm currently working on a library called 'libifconfig' which will provide > a C API to do the actual work that /sbin/ifconfig currently does, except > that of lib80211. What sparked this project was a wish to simplify > maintenance of the ifconfig program by making it primarily focus on the > user's command line interaction, and not so much on the specifics of how > those things are done behind the scenes. > > One advantage to having such a library is to reduce code duplication and > thus improve maintainability, and another is that it would make it easier > for third party programs to query the network stack without having to spawn > ifconfig and parse its output. I'm sure there's more, but those were the > ones at the top of my head when writing this e-mail. > > Currently, the API is implemented so that the application provides an > interface name, required value if any (say, to set description or name), or > a reference to a value if retrieving information, such as an interfaces > description or MTU. > > The calling application won't have to provide a socket, as this is part of > the 'behind the scenes' things that the library takes care of. The API will > ask only for the information that is required to do what it's supposed to > do, nothing more and nothing less. > > Each API call will return a value of either "0" for success or "-1" for > failure and there will be an instance (libifconfig_errstate) of a struct > containing all information relevant to the error. I found this was the most > sensible way of properly communicating exactly what went wrong with a call, > as some API methods do several system calls behind the scenes. I found it > necessary for the API to be this communicative as /sbin/ifconfig is rather > detailed in its error messages, and I don't want /sbin/ifconfig's > behaviour to be altered in any way as a result of this libification. > > The implementation of libifconfig currently exist only on my machine, but I > will submit a patch to reviews.freebsd.org to solicit feedback once I've > cleaned up the code some and implemented & verified the error feedback > mechanism. > > Copy-pasting some of the simple stuff from the header file to give a feel > for how I envision the API: > > int libifconfig_get_description(const char *name, char **description); > int libifconfig_set_description(const char *name, const char > *newdescription); > int libifconfig_unset_description(const char *name); > > int libifconfig_set_mtu(const char *name, const int mtu); > int libifconfig_get_mtu(const char *name, int *mtu); > > > Your feedback is quite welcome. :) > > Regards, > Marie Helene Kvello-Aune > This sounds like an awesome idea. ifconfig is my least favorite program to parse. BTW, are you aware of the ongoing libxo work? That effort fixes the problem of parsing the output of utilities like ifconfig, though it doesn't do anything to simplify their maintenance. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2i0UE4jAfkZspFrs3Zx12-Pf4%2Bqu2Tp3aL8JcVamZd0uw>