From owner-svn-src-head@freebsd.org Sat Apr 15 03:05:55 2017 Return-Path: Delivered-To: svn-src-head@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 AFD6BD3E8AA; Sat, 15 Apr 2017 03:05:55 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84CCE90; Sat, 15 Apr 2017 03:05:55 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v3F35reH009781; Fri, 14 Apr 2017 20:05:53 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v3F35rNJ009780; Fri, 14 Apr 2017 20:05:53 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201704150305.v3F35rNJ009780@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r316938 - head/sbin/savecore In-Reply-To: <4CBF25DF-F407-4F50-8724-B73F64734E19@gmail.com> To: "Ngie Cooper (yaneurabeya)" Date: Fri, 14 Apr 2017 20:05:53 -0700 (PDT) CC: rgrimes@freebsd.org, John Baldwin , Ngie Cooper , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Sat, 15 Apr 2017 03:05:55 -0000 > > > On Apr 14, 2017, at 18:49, Rodney W. Grimes wrote: > > > >> On Friday, April 14, 2017 07:41:48 PM Ngie Cooper wrote: > >>> Author: ngie > >>> Date: Fri Apr 14 19:41:48 2017 > >>> New Revision: 316938 > >>> URL: https://svnweb.freebsd.org/changeset/base/316938 > >>> > >>> Log: > >>> savecore: fix space calculation with respect to `minfree` in check_space(..) > >>> > >>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the > >>> representable data to INT_MAX. Check the values received from > >>> strtoll(3), trimming trailing whitespace off the end to maintain > >>> POLA. > >>> - Use `KiB` instead of `kB` when describing free space, total space, > >>> etc. I am now fully aware of `KiB` being the IEC standard for 1024 > >>> bytes and `kB` being the IEC standard for 1000 bytes. > >> > >> I will just rant lightly that no one actually uses this in the real world. > >> > >> Good lucking finding a "16 GiB" DIMM on crucial.com or a 4Kin drive. A > >> kilobyte is a power of 2. The End. > >> > >> (Next up we'll have to rename 4k displays to > >> 4k) > > > > Do we use KiB, MiB, GiB,... any place else in the system? I cant think of > > a place we do this, so please, lets not start doing this here? > > humanize_number(3) from libutil uses IEC units. And how many things bother to use this library function? Do the ones that do call it produce the traditional output that has been around for 40 years? > > Yes, these are newer standards, perhaps some day we should make a global > > switch to them, but lets not start mixing and matching things. > > I understand and agree. I?m not 100% sold on that one way or another, but > since I was going to redo the number representation in save core with > humanize_number(3), because reading `KiB` is not ideal ^^^ I hope we are not already reading KiB anyplace.... > usability wise, and I don?t want to reinvent the wheel normalizing numbers > and printing out the unit. > > Perhaps there should be a flag baked into humanize_number, etc for parsing IEC vs non-IEC unit values? I dont think it parses anything, but as far as producing strings from values it already has an IEC flag: HN_IEC_PREFIXES, please lets not use this flag, and if we are using it anyplace lets see if we can remove that use. Also be careful, this function only accepts signed int 64, which means we are not gona be able to use this in all places that probably need this, so perhaps a larger can of paint for a bigger bike shead is needed? > Thanks for the input :)! input++; -- Rod Grimes rgrimes@freebsd.org