Hey! Yes, I am aware of libxo, and I hope that libxo-ification of /sbin/ifconfig will be easier to do once the 'hairy' bits aren't a part of /sbin/ifconfig any more. :)
- Marie Helene On Fri, Mar 4, 2016 at 4:20 PM Alan Somers <asom...@freebsd.org> wrote: > On Fri, Mar 4, 2016 at 8:10 AM, Marie Helene Kvello-Aune < > mariehelen...@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 > > _______________________________________________ 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"
