From owner-freebsd-net@freebsd.org Fri Mar 4 15:20:21 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 F3B0F9DB57B for ; Fri, 4 Mar 2016 15:20:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 B9A27846 for ; Fri, 4 Mar 2016 15:20:20 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ob0-x235.google.com with SMTP id rt7so52358345obb.3 for ; Fri, 04 Mar 2016 07:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+qIuQDSb9m+ewehnyOzPhL6dkfYAmnAzDyX3u8/nmGQ=; b=PFhAo22cNFUixSWKwgw4GH1EQdB3VwP3YGj0O0Pn+Hni0R5gVWqZuEoAkYca17QlKc gr21uT08FJk0+F7R7JEMBJMSCaM1IlTC4Emi0qRW8ghVqEQMTAopglpX8nSUOvv7kTJd OvEADM9VWXOGA/scBd+Z4IH6rMPJG90SyocQPgeF/CT8jKAkJ8wbXHr5Qpsg5Q3O5lOy z4Ww0Sgi+scyzjmmaFkOyfOTcATPlIDAPv78lZtj2/e4ZqGdkxTHSpaJBU5D2Y7JwXfi ibPoCpdO//48JBI9ijbMQSmT/51SKpoURIaOe446364lqT1s+g5auLhXlluhVDz363qS oTPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+qIuQDSb9m+ewehnyOzPhL6dkfYAmnAzDyX3u8/nmGQ=; b=VDLbAVhtzxa+ivZC28r/30lV7YBG1rqcUcix0Xyn/n3bLjk7dIy27dvBesQTWbUJlq ZRcMKtOmLlCn38Pk58W3G8tgI/7DnCHj2vMvSJq/5lYrVuI8F8lZXuUjnBkP2thyrlwm ILGW21gNK6o9yWNZdp7qDhMwU3maBOyVeYq7IonAMjc77n8GioDkaLDu9P9fpPK0u4wY MNgKKxvn3J0Rub1Kb2MJJqo6iLO+HVmUNjezpB83vDNRfXS7LjP53IIVbfKFOkWosGpF HvoiKxjWDQQDUcuxbK/3psmSvW5MOfslF/hVPTErPqXGjelkInni9j32w3d5OHDNn7Ur Ks6w== X-Gm-Message-State: AD7BkJJCVkTTJGM5m52BCWix234r1mgUUnsb6YXXv/CCiXBJxNb5s/hrPU/ydG3mNunB1Lm6YWZPcb1NBIj7vA== MIME-Version: 1.0 X-Received: by 10.182.200.196 with SMTP id ju4mr6773865obc.49.1457104819994; Fri, 04 Mar 2016 07:20:19 -0800 (PST) Sender: asomers@gmail.com Received: by 10.202.64.138 with HTTP; Fri, 4 Mar 2016 07:20:19 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 08:20:19 -0700 X-Google-Sender-Auth: qQnzIWVQrzKQk2t2Rr_1xRPnyPI Message-ID: Subject: Re: libifconfig: A C API for ifconfig From: Alan Somers To: Marie Helene Kvello-Aune 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:20:21 -0000 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