lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1460301791-15645-1-git-send-email-alexj@linux.com>
Date:	Sun, 10 Apr 2016 17:23:10 +0200
From:	Alexandru Juncu <alexj@...ux.com>
To:	linux-kernel@...r.kernel.org, den@...nvz.org, mhocko@...e.com,
	redkoi@...tuozzo.com, rkagan@...tuozzo.com, hannes@...xchg.org,
	alexj@...ux.com
Subject: [RFC] proc: meminfo: Replace kB with KiB in output



Hi!

I was helping somebody write some documentation about meminfo and
I started explaining that memory values are mostly multiples of
1024 and that binary prefixes are preferred. The output of
/proc/meminfo is hardcoded to be in 'kB' which should mean 1000
bytes (one kilobytes). But judging by the definition of the K()
macro it is based on page size which is a multiple of 1024.
So the values are actually kibibytes (KiB). Therefore we got
stuck with writing the documentation because there is a
discrepancy between the output and the code.

If I am mistaken, please correct me and ignore the rest of
the message.

I know there is a big debate about using binary prefixes versus
using the de facto definitions based on powers of 10. The
technically correct usage in this case would be KiB but I am
thinking that nobody changed this because it might break things.

Therefore I am writing this email with the main purpose of
finding out what is the reason what the output is as it is.
Is it because changing it would break userspace tools that
read /proc/meminfo ? Or is it because the technical correctness
of the binary prefix side in the debate lost? Or just because
nobody bothered fixing this?

If the last reason is the answer I would like to take the
first step in addressing it with this RFC.

Thank you!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ