From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AA08CC433EF for ; Thu, 16 Dec 2021 15:00:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mBsi0oXBBDWyxFxG7oqpouiX6aCys82Fsz/IqMnIKg4=; b=WLYJ05TmN7lQOt gxIkv0FV1vceNwbKX7yyt260MlNHBZCJwKQn1QcM5KWgIh1E9nrRrtomu1u3n46H+E0w7tpWtrlzq +JxHMt3T21c72ctUiNrF3AJYOBI8KuUWaKwlbOe1T1hShglxXDGQnCX/D0mGesGmgbnkN5gictyYS G1NBxpkwrRkKwaNjLXt0f/aHfFjFJQMhb94mi7n8Rq8jtguthNcrKPh1LKW6KZHm9Vtk6HJnEZ8sC 8JVBjY5B7z48AdCKPzSUdDU/s1p5tXX3Y6L6TbtSdlOWRJSEuGJa9QBIitZBwFmyRQsqbo0Vy7VYJ 1BNmXYkkvxYm/HCcuIsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxsDm-006GDW-Hb; Thu, 16 Dec 2021 14:59:02 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxsDe-006GAa-RE; Thu, 16 Dec 2021 14:58:56 +0000 Received: from zn.tnic (dslb-088-067-202-008.088.067.pools.vodafone-ip.de [88.67.202.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 36B691EC04F0; Thu, 16 Dec 2021 15:58:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1639666729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=bPnAfUL2qkg60kOkbc+GvUrWe3FV49Ti78cms0TCCaw=; b=MsnqJn8uFOT1pz6SXU7T5EbdN02f263mcrgw0HXXo8/ioME2lLYT/8tKVhpgrtQn064RF3 kq0sPjdT1z068sHqWT4pHNiGE8QLCu71aLh7dCkVAIDzqdXcOf5UkmOINkKqu6qCmy2V86 Rt9veDHrpc3QwC1xLsn6Zfaf82ZrDI4= Date: Thu, 16 Dec 2021 15:58:56 +0100 From: Borislav Petkov To: Baoquan He Cc: Zhen Lei , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , Vivek Goyal , Eric Biederman , kexec@lists.infradead.org, Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou Subject: Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel() Message-ID: References: <20211210065533.2023-1-thunder.leizhen@huawei.com> <20211210065533.2023-4-thunder.leizhen@huawei.com> <20211216011040.GG3023@MiWiFi-R3L-srv> <20211216141115.GA18773@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211216141115.GA18773@MiWiFi-R3L-srv> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211216_065855_078608_4E2F0AF7 X-CRM114-Status: GOOD ( 10.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Dec 16, 2021 at 10:11:15PM +0800, Baoquan He wrote: > As for the code refactoring, it can be done in another patchset. Well, I said "future work" before having seen where this patchset is going. So no, in that case, the usual kernel development process is: cleanups/fixes first - new features later. You can see for yourself that piling more crap on what is an already unreadable mess is only going to make it worse. So, in order to avoid the maintenance nightmare, we clean up, streamline, document and then add the new feature and all is shiny. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel