From mboxrd@z Thu Jan 1 00:00:00 1970 From: will.deacon@arm.com (Will Deacon) Date: Tue, 4 Apr 2017 10:26:04 +0100 Subject: [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel In-Reply-To: <1491291844.6218.25.camel@infradead.org> References: <20170328064831.15894-1-takahiro.akashi@linaro.org> <20170328065130.16019-2-takahiro.akashi@linaro.org> <1491207492.6020.8.camel@infradead.org> <20170404054144.GG16309@linaro.org> <20170404073504.GI16309@linaro.org> <1491291844.6218.25.camel@infradead.org> Message-ID: <20170404092604.GB14898@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Date: Tue, 4 Apr 2017 10:26:04 +0100 From: Will Deacon Subject: Re: [PATCH v34 04/14] arm64: kdump: reserve memory for crash dump kernel Message-ID: <20170404092604.GB14898@arm.com> References: <20170328064831.15894-1-takahiro.akashi@linaro.org> <20170328065130.16019-2-takahiro.akashi@linaro.org> <1491207492.6020.8.camel@infradead.org> <20170404054144.GG16309@linaro.org> <20170404073504.GI16309@linaro.org> <1491291844.6218.25.camel@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1491291844.6218.25.camel@infradead.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: David Woodhouse 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 , james.morse@arm.com, Mark Salter , bauerman@linux.vnet.ibm.com, sgoel@codeaurora.org, dyoung@redhat.com, linux-arm-kernel@lists.infradead.org R3V5cywgd2Ugd2VyZSBzdXBwb3NlZCB0byBzdG9wIGRpc2N1c3NpbmcgdGhpcyB0aHJlZSBkYXlz IGFnby4KCk9uIFR1ZSwgQXByIDA0LCAyMDE3IGF0IDA5OjQ0OjA0QU0gKzAyMDAsIERhdmlkIFdv b2Rob3VzZSB3cm90ZToKPiBPbiBUdWUsIDIwMTctMDQtMDQgYXQgMTY6MzUgKzA5MDAsIEFLQVNI SSBUYWthaGlybyB3cm90ZToKPiA+IAo+ID4gQmVjYXVzZSBJIHRoaW5rIHRoYXQgcGVvcGxlIHNv bWV0aW1lcyB1c2UgdGhvc2UgdHdvIGludGVyY2hhbmdlYWJseS4KPiA+IFNvIEkgc2FpZCBJIHdv dWxkIGRlZmVyIHRvIHRoZSBtYWludGFpbmVycy4KPiAKPiBTb21ldGltZXMgdGhleSBkbywgeWVz LiBKdXN0IGFzIHNvbWV0aW1lcyBwZW9wbGUgdXNlICJ0aGVpciIsCj4gInRoZXkncmUiLCBhbmQg InRoZXJlIiBpbnRlcmNoYW5nZWFibHkuCj4gCj4gUmFyZWx5IGluIGEgcHJvZmVzc2lvbmFsIGNv bnRleHQsIHRob3VnaC4gQW5kIGV2ZW4gbW9yZSByYXJlbHkgd2hlbgo+IHRoZWlyIGVycm9yIGhh cyBhbHJlYWR5IGJlZW4gcG9pbnRlZCBvdXQgdG8gdGhlbS4KPiAKPiBUaGVyZSBhcmUgbm8gZ29v ZCByZWFzb25zIHRvICpkZWxpYmVyYXRlbHkqIGdldCBpdCB3cm9uZy4KPiAKPiBJJ3ZlIGhlYXJk IGl0IHN1Z2dlc3RlZCB0aGF0ICdNaUInIHdvdWxkIGNvbmZ1c2UgcGVvcGxlIHdobyBoYXZlIG5l dmVyCj4gc2VlbiBpdCBiZWZvcmUuIEFuZCB0aGF0IGl0IHdhcyB1Z2x5LiBUaG9zZSBhcmd1bWVu dHMgd2VyZSBmYWlybHkKPiBzcGVjaW91cyB3aGVuIHRoZXkgd2VyZSBmaXJzdCBtYWRlLCBhbmQg dGhleSdyZSBldmVuIHNpbGxpZXIgbm93IOKAlCBtb3JlCj4gdGhhbiAyMCB5ZWFycyBzaW5jZSB0 aGUgYmluYXJ5IHByZWZpeGVzIHdlcmUgaW50cm9kdWNlZC4KPiAKPiBUaGUgYWxsZWdlZCBjb25m dXNpb24sIGFuZCB0aGUgcGVyY2VpdmVkIHVnbGluZXNzLCBhcmUgcHVyZWx5IGR1ZSB0bwo+IHVu ZmFtaWxpYXJpdHkgYW5kIHdpbGwgcGFzcy4KPiAKPiBUaGUgY29ycmVjdG5lc3MsIGFuZCB0aGUg bGFjayBvZiBhbWJpZ3VpdHksIHdpbGwgbm90LgoKSSB0aGluayBjb25zaXN0ZW5jeSBjb21lcyBp bnRvIHBsYXkgaGVyZS4gV2UgKGFybTY0KSBhbmQgdGhlIHJlc3Qgb2YgdGhlCmtlcm5lbCBnZXQg dGhpcyB3cm9uZyBhbGwgdGhlIHRpbWUsIHNvIGlmIHdlJ3JlIGdvaW5nIHRvIGZpeCBpdCB0aGVu IHdlCnNob3VsZCBsb29rIGF0IHRoZSB3aWRlciBjb2RlYmFzZSBhbmQgSSdkIHJhdGhlciBub3Qg ZG8gdGhhdCBhcyBwYXJ0IG9mIHRoZQprZHVtcCBzZXJpZXMuIEFsc28sIHdoeSBzdG9wIGF0IHRo ZSBzdWZmaXhlcz8gV2UgZG9uJ3QgaGF2ZSBhbnkgb2NjdXJlbmNlcwpvZiAnbWViaWJ5dGUnIGlu IHRoZSBrZXJuZWwgc291cmNlcywgYnV0IHBsZW50eSBvZiBidXN0ZWQgJ21lZ2FieXRlcycuIEEK cGF0Y2ggbWFraW5nIGFybTY0IGNvbnNpc3RlbnQgY291bGQgYmUgZGlzY3Vzc2VkIHNlcGFyYXRl bHksIG90aGVyd2lzZSBrZHVtcApiZWNvbWVzIHRoZSBwZWRhbnRpYyBJU08gZ3V5IHRyeWluZyB0 byBsZWFkIGJ5IGV4YW1wbGUsIGJ1dCByZWFsbHkgZXZlcnlib2R5Cmlnbm9yZXMgaGltIGJlY2F1 c2UgaXQncyBjb21wbGV0ZWx5IGluY29uc2VxdWVudGlhbCBhbmQgdGhleSBhbHNvIGtub3cgaGUK d2VudCAzNSB2ZXJzaW9ucyB3aXRob3V0IGdpdmluZyBhIG1vbmtleSdzLgoKRGF2aWQsIHNpbmNl IHlvdSBzZWVtIHRvIGJlIHRoZSBtb3N0IG91dHJhZ2VkLCBmYW5jeSBzZW5kaW5nIGEgcGF0Y2g/ IDspCgpBbHRlcm5hdGl2ZWx5LCB3aG8gZmFuY2llcyBidXJuaW5nIHNvbWUgZGljdGlvbmFyaWVz PwoKV2lsbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K a2V4ZWMgbWFpbGluZyBsaXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3Rz LmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9rZXhlYwo=