From owner-svn-src-all@freebsd.org Thu Aug 25 20:20:27 2016 Return-Path: Delivered-To: svn-src-all@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 C2251BC4313; Thu, 25 Aug 2016 20:20:27 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D2691822; Thu, 25 Aug 2016 20:20:27 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.228.1] (ptr-2hj4tbph7h3f9zbx59wy7lior.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:c18a:e29e:ca57:c0db]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id A01B7AC3C; Thu, 25 Aug 2016 22:20:25 +0200 (CEST) From: "Kristof Provost" To: "John Baldwin" , "Marie Helene Kvello-Aune" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304815 - in head: lib lib/libifc share/examples/libifc share/mk Date: Thu, 25 Aug 2016 22:20:29 +0200 Message-ID: <1A050E0F-4B9F-420A-97C6-C203B92A5F3F@FreeBSD.org> In-Reply-To: <23395083.lPEyYQ7ZbW@ralph.baldwin.cx> References: <201608251940.u7PJePv3023083@repo.freebsd.org> <23395083.lPEyYQ7ZbW@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (2.0BETAr6052) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 20:20:27 -0000 On 25 Aug 2016, at 22:14, John Baldwin wrote: > On Thursday, August 25, 2016 07:40:25 PM Kristof Provost wrote: >> Author: kp >> Date: Thu Aug 25 19:40:25 2016 >> New Revision: 304815 >> URL: https://svnweb.freebsd.org/changeset/base/304815 >> >> Log: >> Add libifc, a library implementing core functionality that exists >> in ifconfig(8) today. >> >> libifc (pronounced lib-ifconfig) aims to be a light abstraction >> layer between >> programs and the kernel APIs for managing the network >> configuration. >> This should hopefully make programs easier to maintain, and reduce >> code >> duplication. >> >> Work will begin on making ifconfig(8) use this library in the near >> future. >> >> This code is still evolving. The interface should not be considered >> stable until >> it is announced as such. > > I hate even writing this mail, and it looks like the topic wasn't > really > discussed in the review, but I think libifconfig is probably the > "better" > name if the goal is to move most of ifconfig into it. Certainly if a > developer is looking for a library that provides a programmatic > interface > to the same operations a user does via ifconfig, libifconfig is the > name > they will look for first. > > One thing I did see in the review is that the APIs use 'ifc_*' and > that was > the reason given for renaming the library. If you really want those > to be > in sync, I actually think the longer 'ifconfig_*' prefix isn't that > terrible. > We have other libraries that use similar length names and namespace > prefixes > already (libarchive, libdevctl, libdevinfo, libpthread). > > Hmm, it seems you are 'libifc_*'. Most of our libraries do not > include > 'lib' in the namespace prefix (see above examples that all use the > name of > the library without 'lib' as the prefix). If nothing else I'd suggest > dropping 'lib' to be consistent with most other libraries in the tree. This is the right time to bring this sort of thing up. One of the reasons I pushed to get this in the tree in this very early state was to provoke exactly this sort of response. Right now the work is still in an early state and changing this sort of thing is still possible. The name was in fact discussed privately, and we figured libifconfig was a bit on the long side. I certainly take your point about libifc_. Does anyone else have any views regarding the naming (or other subjects)? Regards, Kristof