Date: Fri, 14 Apr 2017 20:31:11 -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: <201704150331.v3F3VB5b009905@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <1DC7F131-3EC6-4C59-8941-DC3EE77764C2@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Charset UTF-8 unsupported, converting... ] > > > On Apr 14, 2017, at 20:05, Rodney W. Grimes <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > > > >>> > >>> 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?. > > I meant it?s a lot harder for humans to read `<really-long-int>KiB` > instead of `<appropriately-scaled-int><appropriate-byte-unit>`. And I am agreeing on the scaled, and disagreeing on the KiB, another words please revert to printing KB as the former code did as far as a Unit goes. Lets not use Ki Mi Gi, etc. > >> 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. > > I don?t see it used anywhere in the tree, based on a quick grep. YEA!!! Thanks for doing the search. > > 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? > > I don?t necessarily follow the above statement 100%. Are you warning > against mass-conversion to libutil (if so, I agree? this was just a case > where it really helps readability in savecore(8))? Yes, I am warning against mass conversion, or for that that matter much conversion to humanize_number because it shall need to be revamped if it is ever to become a real solutions due to it being a very narrow minded function (no unsigned implementation for very large values that are probably the ones that could benifit the most from this type of function.) You also may want to still report full sizes in output (you maybe I have not read the final code:) >From kernel boot: real memory = 134217728 (128 MB) avail memory = 120832000 (115 MB) -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704150331.v3F3VB5b009905>