From owner-freebsd-net@freebsd.org Fri Mar 4 15:10:24 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 4357E9DB202 for ; Fri, 4 Mar 2016 15:10:24 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 E670DFE1 for ; Fri, 4 Mar 2016 15:10:23 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id p65so32938628wmp.0 for ; Fri, 04 Mar 2016 07:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=12gCECmkBZGZ1ZQ9phh4LY7sgpySLwSS1feltRQa6XA=; b=xocgDwLmYQs7LLsNkGUco5T4f7FQeJt2hmq2DCQPgaOv5nm3yyybx8LdHm86ujKERT oxzgGab5BMMjP3sQstKhwffBgHLHI+K3jElNdGfJj9v3oF5MqzIS1/vITZq2qzGEnAqW N52MkFY6XdAPEa3Q7ifZpJpVxNKpkYtDDfKB6tOB/LXzEfy46YTfpUnUdSYmJdtAWz8b fRkez46fWup8yS4O1XRXi71cVvTiMUJAB072rEuwSZOIPOaEXi3SX5x3YXO2PgLxTIqg egKBLLZJWXTPM5E5QFseGgjdyBGDXfrJJ8jqhhzBzDUJIWBtuO0Yx09+Y4Ut2YPqtxAK fsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=12gCECmkBZGZ1ZQ9phh4LY7sgpySLwSS1feltRQa6XA=; b=Uas8RXphl4cdg3V9QBYCKr/v8D4W67KXhW2ZV5PhbyRCnx7zb0TSTI1y28GPKAH3hP MkUvfnsjIZ9wqHv9vxam59RCy6Nr50UWQ2em6Mz/Is6XZnTPqS/zij+pr8pg6kKcxMzU Ym4vxnDnlT2ELYbqfHOo9CW/5nvmPcESvY68W8hWCM/hiOA+/BSIrxiHpc9/gn87Szem rZaK2WMUHJvmJwxYTBZwtmtaBH0vJPKodz2VcT59rhlqhRLlP+GwH6oFWFUgMvJEsY5u zU8iVYfmdTaXXPSwPNF81JmN+39gP/GBUX1GQm343Pgqd51nEQvzgkKuThEebssstZ7c ahKw== X-Gm-Message-State: AD7BkJIIvipTKaaVuND6jyIbyisEAC+jGXWwfpzZIb0Fd6po4GnbOAplLXS5ocI6A2GKCUTz2a24o9q/7p03OA== X-Received: by 10.194.78.199 with SMTP id d7mr9700678wjx.106.1457104221939; Fri, 04 Mar 2016 07:10:21 -0800 (PST) MIME-Version: 1.0 From: Marie Helene Kvello-Aune Date: Fri, 04 Mar 2016 15:10:12 +0000 Message-ID: Subject: libifconfig: A C API for ifconfig To: freebsd-net@freebsd.org 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:10:24 -0000 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