svn commit: r316938 - head/sbin/savecore

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2017, at 20:05, Rodney W. Grimes <freebsd at pdx.rh.CN85.dnsmgr.net> wrote:
> 
>>> 
>>> On Apr 14, 2017, at 18:49, Rodney W. Grimes <freebsd at 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>`.

>> 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.

> 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))?

Thanks!
-Ngie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20170414/c96d9963/attachment.sig>