Hello! Great idea! Amazing! :)
On Fri, Mar 4, 2016 at 6:25 PM, Marie Helene Kvello-Aune <mariehelen...@gmail.com> wrote: > 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" -- Sincerely yours, Pavel Odintsov _______________________________________________ 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"
