linux-kernel - [RFC] proc: meminfo: Replace kB with KiB in output

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]

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!