All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel
Date: Tue, 4 Apr 2017 10:26:04 +0100	[thread overview]
Message-ID: <20170404092604.GB14898@arm.com> (raw)
In-Reply-To: <1491291844.6218.25.camel@infradead.org>

Guys, we were supposed to stop discussing this three days ago.

On Tue, Apr 04, 2017 at 09:44:04AM +0200, David Woodhouse wrote:
> On Tue, 2017-04-04 at 16:35 +0900, AKASHI Takahiro wrote:
> > 
> > Because I think that people sometimes use those two interchangeably.
> > So I said I would defer to the maintainers.
> 
> Sometimes they do, yes. Just as sometimes people use "their",
> "they're", and "there" interchangeably.
> 
> Rarely in a professional context, though. And even more rarely when
> their error has already been pointed out to them.
> 
> There are no good reasons to *deliberately* get it wrong.
> 
> I've heard it suggested that 'MiB' would confuse people who have never
> seen it before. And that it was ugly. Those arguments were fairly
> specious when they were first made, and they're even sillier now ? more
> than 20 years since the binary prefixes were introduced.
> 
> The alleged confusion, and the perceived ugliness, are purely due to
> unfamiliarity and will pass.
> 
> The correctness, and the lack of ambiguity, will not.

I think consistency comes into play here. We (arm64) and the rest of the
kernel get this wrong all the time, so if we're going to fix it then we
should look at the wider codebase and I'd rather not do that as part of the
kdump series. Also, why stop at the suffixes? We don't have any occurences
of 'mebibyte' in the kernel sources, but plenty of busted 'megabytes'. A
patch making arm64 consistent could be discussed separately, otherwise kdump
becomes the pedantic ISO guy trying to lead by example, but really everybody
ignores him because it's completely inconsequential and they also know he
went 35 versions without giving a monkey's.

David, since you seem to be the most outraged, fancy sending a patch? ;)

Alternatively, who fancies burning some dictionaries?

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: mark.rutland@arm.com, panand@redhat.com,
	ard.biesheuvel@linaro.org, geoff@infradead.org,
	catalin.marinas@arm.com, kexec@lists.infradead.org,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	james.morse@arm.com, Mark Salter <msalter@redhat.com>,
	bauerman@linux.vnet.ibm.com, sgoel@codeaurora.org,
	dyoung@redhat.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel
Date: Tue, 4 Apr 2017 10:26:04 +0100	[thread overview]
Message-ID: <20170404092604.GB14898@arm.com> (raw)
In-Reply-To: <1491291844.6218.25.camel@infradead.org>

Guys, we were supposed to stop discussing this three days ago.

On Tue, Apr 04, 2017 at 09:44:04AM +0200, David Woodhouse wrote:
> On Tue, 2017-04-04 at 16:35 +0900, AKASHI Takahiro wrote:
> > 
> > Because I think that people sometimes use those two interchangeably.
> > So I said I would defer to the maintainers.
> 
> Sometimes they do, yes. Just as sometimes people use "their",
> "they're", and "there" interchangeably.
> 
> Rarely in a professional context, though. And even more rarely when
> their error has already been pointed out to them.
> 
> There are no good reasons to *deliberately* get it wrong.
> 
> I've heard it suggested that 'MiB' would confuse people who have never
> seen it before. And that it was ugly. Those arguments were fairly
> specious when they were first made, and they're even sillier now — more
> than 20 years since the binary prefixes were introduced.
> 
> The alleged confusion, and the perceived ugliness, are purely due to
> unfamiliarity and will pass.
> 
> The correctness, and the lack of ambiguity, will not.

I think consistency comes into play here. We (arm64) and the rest of the
kernel get this wrong all the time, so if we're going to fix it then we
should look at the wider codebase and I'd rather not do that as part of the
kdump series. Also, why stop at the suffixes? We don't have any occurences
of 'mebibyte' in the kernel sources, but plenty of busted 'megabytes'. A
patch making arm64 consistent could be discussed separately, otherwise kdump
becomes the pedantic ISO guy trying to lead by example, but really everybody
ignores him because it's completely inconsequential and they also know he
went 35 versions without giving a monkey's.

David, since you seem to be the most outraged, fancy sending a patch? ;)

Alternatively, who fancies burning some dictionaries?

Will

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2017-04-04  9:26 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28  6:48 [PATCH v34 00/14] arm64: add kdump support AKASHI Takahiro
2017-03-28  6:48 ` AKASHI Takahiro
2017-03-28  6:50 ` [PATCH v34 01/14] memblock: add memblock_clear_nomap() AKASHI Takahiro
2017-03-28  6:50   ` AKASHI Takahiro
2017-03-28  6:50   ` AKASHI Takahiro
2017-03-28  9:47   ` Ard Biesheuvel
2017-03-28  9:47     ` Ard Biesheuvel
2017-03-28  9:47     ` Ard Biesheuvel
2017-03-28  6:50 ` [PATCH v34 02/14] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2017-03-28  6:50   ` AKASHI Takahiro
2017-03-28  6:50   ` AKASHI Takahiro
2017-03-28  9:48   ` Ard Biesheuvel
2017-03-28  9:48     ` Ard Biesheuvel
2017-03-28  9:48     ` Ard Biesheuvel
2017-03-28  6:51 ` [PATCH v34 03/14] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  9:50   ` Ard Biesheuvel
2017-03-28  9:50     ` Ard Biesheuvel
2017-03-28  6:51 ` [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  9:52   ` Ard Biesheuvel
2017-03-28  9:52     ` Ard Biesheuvel
2017-04-03  8:18   ` David Woodhouse
2017-04-03  8:18     ` David Woodhouse
2017-04-04  5:41     ` AKASHI Takahiro
2017-04-04  5:41       ` AKASHI Takahiro
2017-04-04  6:14       ` David Woodhouse
2017-04-04  6:14         ` David Woodhouse
2017-04-04  7:35         ` AKASHI Takahiro
2017-04-04  7:35           ` AKASHI Takahiro
2017-04-04  7:39           ` Ard Biesheuvel
2017-04-04  7:39             ` Ard Biesheuvel
2017-04-04  7:44           ` David Woodhouse
2017-04-04  7:44             ` David Woodhouse
2017-04-04  9:26             ` Will Deacon [this message]
2017-04-04  9:26               ` Will Deacon
2017-04-13 12:15               ` David Woodhouse
2017-04-13 12:15                 ` David Woodhouse
2017-04-13 12:17               ` [PATCH 1/2] arm64: Fix power-of-ten vs. power-of-two prefixes in user-visible messages David Woodhouse
2017-04-13 12:17                 ` David Woodhouse
2017-04-19  9:29                 ` Geert Uytterhoeven
2017-04-19  9:29                   ` Geert Uytterhoeven
2017-04-13 12:18               ` [PATCH 2/2] arm64: Fix power-of-ten vs. power-of-two prefixes in comments etc David Woodhouse
2017-04-13 12:18                 ` David Woodhouse
2017-04-16 23:12                 ` Simon Horman
2017-04-16 23:12                   ` Simon Horman
2017-04-16 23:12                   ` Simon Horman
2017-04-17 11:54                   ` Geert Uytterhoeven
2017-04-17 11:54                     ` Geert Uytterhoeven
2017-04-17 11:54                     ` Geert Uytterhoeven
2017-04-18 14:13                     ` Catalin Marinas
2017-04-18 14:13                       ` Catalin Marinas
2017-04-18 14:13                       ` Catalin Marinas
2017-04-19 14:25                       ` Olof Johansson
2017-04-19 14:25                         ` Olof Johansson
2017-04-19 14:25                         ` Olof Johansson
2017-03-28  6:51 ` [PATCH v34 05/14] arm64: mm: add set_memory_valid() AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  9:54   ` Ard Biesheuvel
2017-03-28  9:54     ` Ard Biesheuvel
2017-03-28  6:51 ` [PATCH v34 06/14] arm64: kdump: protect crash dump kernel memory AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28 10:07   ` Ard Biesheuvel
2017-03-28 10:07     ` Ard Biesheuvel
2017-03-28 11:07     ` AKASHI Takahiro
2017-03-28 11:07       ` AKASHI Takahiro
2017-03-28 14:05       ` Ard Biesheuvel
2017-03-28 14:05         ` Ard Biesheuvel
2017-03-30  9:56         ` AKASHI Takahiro
2017-03-30  9:56           ` AKASHI Takahiro
2017-03-30 13:58           ` Ard Biesheuvel
2017-03-30 13:58             ` Ard Biesheuvel
2017-04-03  2:28             ` AKASHI Takahiro
2017-04-03  2:28               ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 07/14] arm64: hibernate: preserve kdump image around hibernation AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 08/14] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 09/14] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 10/14] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 11/14] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
2017-03-28  6:51 ` [PATCH v34 12/14] Documentation: kdump: describe arm64 port AKASHI Takahiro
2017-03-28  6:51   ` AKASHI Takahiro
     [not found] ` <20170328064831.15894-1-takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-03-28  6:52   ` [PATCH v34 13/14] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2017-03-28  6:52     ` AKASHI Takahiro
2017-03-28  6:52     ` AKASHI Takahiro
2017-03-28  6:53   ` [PATCH v34 14/14] efi/libstub/arm*: Set default address and size cells values for an empty dtb AKASHI Takahiro
2017-03-28  6:53     ` AKASHI Takahiro
2017-03-28  6:53     ` AKASHI Takahiro
2017-03-28 10:08     ` Ard Biesheuvel
2017-03-28 10:08       ` Ard Biesheuvel
2017-03-28 10:08       ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170404092604.GB14898@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.