Date: Fri, 14 Apr 2017 20:12:15 -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: <1DC7F131-3EC6-4C59-8941-DC3EE77764C2@gmail.com> In-Reply-To: <201704150305.v3F35rNJ009780@pdx.rh.CN85.dnsmgr.net> References: <201704150305.v3F35rNJ009780@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_9A2FC2C8-030A-456C-B117-169918E25B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2017, at 20:05, Rodney W. Grimes = <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: >=20 >>>=20 >>> 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? >>=20 >> humanize_number(3) from libutil uses IEC units. >=20 > 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? >=20 >>> Yes, these are newer standards, perhaps some day we should make a = global >>> switch to them, but lets not start mixing and matching things. >>=20 >> 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=E2=80=A6. I meant it=E2=80=99s 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. >>=20 >> Perhaps there should be a flag baked into humanize_number, etc for = parsing IEC vs non-IEC unit values? >=20 > 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=E2=80=99t 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=E2=80=99t necessarily follow the above statement 100%. Are you = warning against mass-conversion to libutil (if so, I agree=E2=80=A6 this = was just a case where it really helps readability in savecore(8))? Thanks! -Ngie --Apple-Mail=_9A2FC2C8-030A-456C-B117-169918E25B68 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 iQIcBAEBCgAGBQJY8Y+QAAoJEPWDqSZpMIYVX5kP/A0O7rb3xexdwfkxcWpizQG2 LqVrwCJfslZsuleUKtxWlaf1DH+uOBihXhlFYv5wjDBFkdw+fkzrQf9XdREElceF 35L7XOWZVvzriL2sBLH2VkK+xa9W2k60zJIRKefRtij1GDxvzq7EmoOFHZB6qUhk LAswQb2qrxdEhKJ8fHbKLBTTcYFm7/IQzUX61+lZiOtcsZ08iDCzW/NP6XBNoy26 VHwKGWUHcAp/fY4le80ie2NeLL96Av2TpSkDmTAKwI2qdGSV6eLkpgzf7AN8Y9HV A1YNuq1eC5LOAUnU7DuyT4Qaj96eDhpkRSMeFQ66OWIxCnxqby0HXPn2bvAN8TaM wPyC7GnvGZSTVUBtGumYMrWbdvz/zxRJGXwTKcoHpci+PPI6RlDUGmsE2dUZcLgo Xg+oh1wvp14JGl2woNmjmF7dlCZy7UjWjIT4bxw0EkKx20Vg0pIe1KDgUGSdAGDF lafih0LxFWO57hO3aa+bE/U5s0SeTN0uRmLQy3xQjD5Dx63INpJcOCMq2F6wqb3u E3vfiIuF1nhU2SYu67cL61R+haiG7rgUOZRFsWaOHIDrEbEYBG/pnevJNu+1DzeU tzomNMV1J2nK1aMc97Y28eiEe9soFiQOP5lq0HHSbU4G+B+OI8tp1hm8Q/D4MlPb 59fBblARl1BM9i6qsIHC =QKDO -----END PGP SIGNATURE----- --Apple-Mail=_9A2FC2C8-030A-456C-B117-169918E25B68--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DC7F131-3EC6-4C59-8941-DC3EE77764C2>