Date: Fri, 14 Apr 2017 20:05:53 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com> Cc: rgrimes@freebsd.org, John Baldwin <jhb@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <201704150305.v3F35rNJ009780@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <4CBF25DF-F407-4F50-8724-B73F64734E19@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On Apr 14, 2017, at 18:49, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> 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<insert arbitrary and unrelated letter here>) > > > > 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 `<really-long-int>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704150305.v3F35rNJ009780>