From owner-freebsd-net@freebsd.org Fri Mar 4 15:25:25 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E585E9DB7B1 for ; Fri, 4 Mar 2016 15:25:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91A85BB3; Fri, 4 Mar 2016 15:25:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id p65so24850153wmp.1; Fri, 04 Mar 2016 07:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UN9ZLz9SuM+znnOTBeGpEKT/VOy6F2iSIrZqFwy0zPI=; b=ltHTr2lBjkfZAsVrFoxrliO7Uxt/K4HYJmtkFM19nzLEo25G5kFcUIOg+PQnVhvdoL 3cmsXRnxJjfcHrSwKP+pf6wHHZ9YfHLntzpr05x8xdWXb5Rc20wAHJLKYwaDxZP+QZk1 QrFTMgAZSYJIXfd7/xb8C1tN/oOqDlRH6cjuN2//Sh/DevuMnsVIaOh7bKpUY9/r2oa3 2hilkOTw6156jgEF0oY/ILYaXfM+jnZjNAA8UNbyVl4QFVcS/iZ3XA9PLR8WAqiDBAHR bRWYaI0bOaHa5v7aIvXE0Ees8NnZtZZYzIF0sntGVZAbo/ebBxP5Ids3kjpJI1JeIlzs xZ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UN9ZLz9SuM+znnOTBeGpEKT/VOy6F2iSIrZqFwy0zPI=; b=ZrvenJY283taigFF2x3nSDot37xA0SKWkCqoJlv8iz5hlz1okeyJ0neWl4je+Q//So S9GyWybjX0dAa7dgW/qKU3nZzXevxq87h+aHi5he7iSLcP/SPYBKXF/uO9ZWeizxq0J1 dCdA0rIUYLC2DCC6LsgkwJB7Mj3hAt/C8CzcbxvKMeaUmFuAghX/oO4CXwiuBX4FiBLG pKYcP+pCczf/qx66iTanwKzeKBNSw0NmLzwfsFzRAVjMRIjhn6X2wTmjHSENK+kp7nxK Ycmc++CGknzOEv+tqwh2IiUMLjCWzX9tQSqqJIdAxHuanimUMnPu/kct4Qm5ikb1KZHU rSVw== X-Gm-Message-State: AD7BkJLHogR+GKrALCfBkQv6bIodobYRrd2c6iqVV8nXPHylTYTDpD+g/Pgf77oLW49ejgz5FVTOwRBsJjudGQ== X-Received: by 10.28.90.68 with SMTP id o65mr5566724wmb.70.1457105123100; Fri, 04 Mar 2016 07:25:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marie Helene Kvello-Aune Date: Fri, 04 Mar 2016 15:25:13 +0000 Message-ID: Subject: Re: libifconfig: A C API for ifconfig To: Alan Somers Cc: FreeBSD Net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:25:25 -0000 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 wrote: > 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 > >