From owner-svn-src-head@freebsd.org Fri Jul 27 15:44:09 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4B55104EBE3; Fri, 27 Jul 2018 15:44:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 602567AA09; Fri, 27 Jul 2018 15:44:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w6RFi0jc017064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jul 2018 18:44:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w6RFi0jc017064 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w6RFhxDP017053; Fri, 27 Jul 2018 18:43:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 27 Jul 2018 18:43:59 +0300 From: Konstantin Belousov To: Ian Lepore Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336746 - in head/lib: libc/gen libutil Message-ID: <20180727154359.GB2489@kib.kiev.ua> References: <201807261834.w6QIYc9i080738@repo.freebsd.org> <20180727150304.GA2489@kib.kiev.ua> <1532705741.61594.53.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1532705741.61594.53.camel@freebsd.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2018 15:44:09 -0000 On Fri, Jul 27, 2018 at 09:35:41AM -0600, Ian Lepore wrote: > On Fri, 2018-07-27 at 18:03 +0300, Konstantin Belousov wrote: > > On Thu, Jul 26, 2018 at 06:34:38PM +0000, Ian Lepore wrote: > > > > > > Author: ian > > > Date: Thu Jul 26 18:34:38 2018 > > > New Revision: 336746 > > > URL: https://svnweb.freebsd.org/changeset/base/336746 > > > > > > Log: > > > š Make pw_scan(3) more compatible with getpwent(3) et. al. when processing > > > š data from /etc/passwd rather than /etc/master.passwd. > > > šš > > > š The libc getpwent(3) and related functions automatically read master.passwd > > > š when run by root, or passwd when run by a non-root user.ššWhen run by non- > > > š root, getpwent() copes with the missing data by setting the corresponding > > > š fields in the passwd struct to known values (zeroes for numbers, or a > > > š pointer to an empty string for literals).ššWhen libutil's pw_scan(3) was > > > š used to parse a line without the root-accessible data, it was leaving > > > š garbage in the corresponding fields. > > > šš > > > š These changes rename the static pw_init() function used by getpwent() and > > > š friends to __pw_initpwd(), and move it into pw_scan.c so that common init > > > š code can be shared between libc and libutil.ššpw_scan(3) now calls > > > š __pw_initpwd() before __pw_scan(), just like the getpwent() family does, so > > > š that reading an arbitrary passwd file in either format and parsing it with > > > š pw_scan(3) returns the same results as getpwent(3) would. > > > šš > > > š This also adds a new pw_initpwd(3) function to libutil, so that code which > > > š creates passwd structs from scratch in some manner that doesn't involve > > > š pw_scan() can initialize the struct to the values expected by lots of > > > š existing code, which doesn't expect to encounter NULL pointers or garbage > > > š values in some fields. > > > > > If my reading is right, you just made libutil depend on the internal > > libc interfaces. Formal consequence is that libutil.so version must > > be bumped each time the used interface is changed (and it is allowed > > to change). I think that your change actually requires the bump of > > libutil.so.N version already. > > > > Also, libutil.so.N should be moved from the libutil pkgbase package to > > the clibs package, I am not sure about this. > > > > At the higher level, I very much dislike this change. FBSDprivate_1.0 > > namespace is for symbols providing the internal interfaces for the > > C runtime implementation in the FreeBSD. This is mostly a knot of > > inter-dependencies between rtld, libc and libthr. libutil arguably > > should not participate. > > > > If you want for libc to provide a functionality outside the C runtime, > > please make the sustainable interface, which ABI can be maintained, and > > export the symbols in the normal namespace, with the usual stability > > guarantees. > > There was already a function, __pw_scan(), in file pw_scan.c, which was > called from both libutil and libc implementations. I added a new > function __pw_initpwd() into the pw_scan.c file. That function is > called from all the same places that __pw_scan() is called from. So as > near as I can tell, I haven't changed the structure of anything or > created any new linkages between the libraries that didn't exist > already. > > I will admit I don't understand thešFBSDprivate_1.0 stuff at all, and > there appears to be no documentation or guidance on how to work with > it. Since __pw_scan was in the private list, and I was adding a new > function that is like it in every way, I reasoned that the new function > should be in the list too. It's actually not clear to me that either of > the functions should be in that list, but like I said... no published > info about it that I could find. > > I also noticed that chpass(1) and pwd_mkdb(8)_both directly compile in > their own copy of the pw_scan.c source using .PATH in their makefiles. > I wonder if doing that as the way of sharing the code between libc and > libutil would be a better thing to do? (And presumably that would > remove the need to have entries in the FBSDprivate_1.0 list?) I suspect that the better way is to export the used functions in the FBSD_1.5 namespace. Might be use the opportunity to rename them, in particular, remove the leading double underscore. Might be, reconsider the interfaces to make them more generic. Do the consumers depend on the specific layout of some structure ?