Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Apr 2017 19:40:57 -0700
From:      "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>
To:        rgrimes@freebsd.org
Cc:        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:  <4CBF25DF-F407-4F50-8724-B73F64734E19@gmail.com>
In-Reply-To: <201704150149.v3F1nu0D009274@pdx.rh.CN85.dnsmgr.net>
References:  <201704150149.v3F1nu0D009274@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_D704F685-4935-47FC-9D53-C6152B6B9F90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Apr 14, 2017, at 18:49, Rodney W. Grimes =
<freebsd@pdx.rh.CN85.dnsmgr.net> wrote:
>=20
>> 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
>>>=20
>>> Log:
>>>  savecore: fix space calculation with respect to `minfree` in =
check_space(..)
>>>=20
>>>  - 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.
>>=20
>> I will just rant lightly that no one actually uses this in the real =
world.
>>=20
>> Good lucking finding a "16 GiB" DIMM on crucial.com or a 4Kin drive.  =
A
>> kilobyte is a power of 2.  The End.
>>=20
>> (Next up we'll have to rename 4k displays to
>> 4k<insert arbitrary and unrelated letter here>)
>=20
> 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.

> 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=E2=80=99m 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 usability wise, and I don=E2=80=99t 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?

Thanks for the input :)!
-Ngie

--Apple-Mail=_D704F685-4935-47FC-9D53-C6152B6B9F90
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJY8Yg5AAoJEPWDqSZpMIYVGtkP/RkTXwoej2EaIuPE/hJDOKk1
aKqIsNETeXbzHEeLnIxGMIdEjdxPLSQ7blIMsju67lFBRi0CDnYOHNa2Qy6cltUC
ZclqMH+1wkvenu8j5H13KMeqjclXLHnmZJ8HzZfTTjhAUE9k/tYFl/UCEigDFe7w
vhwfa2l06D+jPXQuM/pb3TqFrwPKv4x1EB/EYhnhSzgexgXZ5sxxBeHM9+uFfeC4
+62M60IpJWDotj1quAicYtWHqrtGtpVl62LRcRFJ664kfcqch1/5YhB7u4Ow4d1g
g1BJYcgS1WAsCqBT0tACACWnJMEk1GR0vxCDFqYbEabnGJ1BQPSp9ctd+7PHjvQq
vCHe0kYE+jiYgkvo8E+wBanuVM9bjWeuRqijiwr9jQ+cE4LXr61A7wnWdJpsE6O7
LghVkG/keWkv0Mev5TdsOg73TlW8yDauo/GlIczeB2U7EIDe6h8MYFF5FvtNuUpd
40BIjwEw5gidp4luiWDmk4aVKMNYqBmV9t4RcNZ2uh496bFtW+cCLjl108xkxuf6
Ue/BLDzWE7kn93F/wBG3qfkQ5LQGrVaUE7vTxP5LeVks5fvxsqn1YYt4E+pkm8ZN
4BaqBrd7mobgGJgB3i+X9AD9R2iOlyprVSfBDhl1xhR+/z+MhflWIp8JwGQppnjL
v3QKHADSxxOA2QhmXztk
=q2LA
-----END PGP SIGNATURE-----

--Apple-Mail=_D704F685-4935-47FC-9D53-C6152B6B9F90--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBF25DF-F407-4F50-8724-B73F64734E19>