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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7928DC433F5 for ; Wed, 29 Dec 2021 14:13:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240123AbhL2ON1 (ORCPT ); Wed, 29 Dec 2021 09:13:27 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:15990 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236061AbhL2ON0 (ORCPT ); Wed, 29 Dec 2021 09:13:26 -0500 Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4JPCwF5HSczVhMD; Wed, 29 Dec 2021 22:10:05 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 29 Dec 2021 22:13:24 +0800 Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 29 Dec 2021 22:13:22 +0800 Subject: Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code To: Dave Young , Borislav Petkov CC: Thomas Gleixner , Ingo Molnar , , "H . Peter Anvin" , , Baoquan He , Vivek Goyal , Eric Biederman , , Catalin Marinas , "Will Deacon" , , Rob Herring , Frank Rowand , , Jonathan Corbet , , Randy Dunlap , Feng Zhou , Kefeng Wang , "Chen Zhou" , John Donnelly References: <20211228132612.1860-1-thunder.leizhen@huawei.com> <20211228132612.1860-3-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <050a33f3-7a87-62ce-00bb-92b5d30915d1@huawei.com> Date: Wed, 29 Dec 2021 22:13:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/12/29 18:38, Dave Young wrote: > On 12/29/21 at 11:11am, Borislav Petkov wrote: >> On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote: >>> BTW, I would suggest to wait for reviewers to response (eg. one week at >>> least, or more due to the holidays) before updating another version >>> >>> Do not worry to miss the 5.17. I would say take it easy if it will >>> miss then let's just leave with it and continue to work on the future >>> improvements. I think one reason this issue takes too long time is that it was >>> discussed some time but no followup and later people need to warm up >>> again. Just keep it warm and continue to engage in the improvements, do >>> not hurry for the specific mainline release. >> >> Can you tell this to *all* patch submitters please? > > I appreciate you further explanation below to describe the situation. I do not > see how can I tell this to *all* submitters, but I am and I will try to do this > as far as I can. Maintainers and patch submitters, it would help for both > parties show sympathy with each other, some soft reminders will help > people to understand each other, especially for new comers. > >> >> I can't count the times where people simply hurry to send the new >> revision just to get it in the next kernel, and make silly mistakes >> while doing so. Or not think things straight and misdesign it all. >> >> And what this causes is the opposite of what they wanna achieve - pissed >> maintainers and ignored threads. I just hope the first 4 patches can be merged into v5.17. It seems to me that it is quite clear. Although the goal of the final stage is to modify function parse_crashkernel() according to the current opinion. But that's not a lightweight change after all. The final parse_crashkernel() change may take one version or two. In this process, it maybe OK to do a part of cleanup first. It's like someone who wants to buy a luxury car to commute to work six months later. He buys a cheap used car and sells it six months later. It sounds right to me, don't you think? >> >> And they all *know* that the next kernel is around the corner. So why >> the hell does it even matter when? Because all programmers should have confidence in the code they write. I have a new idea, and I'm free these days, so I updated v19. I can't rely on people telling me to take a step forward, then take a step forward. Otherwise, stand still. >> >> What most submitters fail to realize is, the moment your code hits >> upstream, it becomes the maintainers' problem and submitters can relax. Sorry, I'll make sure all the comments are collected and then send the next edition. >> >> But maintainers get to deal with this code forever. So after a while >> maintainers learn that they either accept ready code and it all just >> works or they make the mistake to take half-baked crap in and then they >> themselves get to clean it up and fix it. >> >> So maintainers learn quickly to push back. >> >> But it is annoying and it would help immensely if submitters would >> consider this and stop hurrying the code in but try to do a *good* job >> first, design-wise and code-wise by thinking hard about what they're >> trying to do. >> >> Yeah, things could be a lot simpler and easier - it only takes a little >> bit of effort... >> >> -- >> Regards/Gruss, >> Boris. >> >> https://people.kernel.org/tglx/notes-about-netiquette >> > > Thanks > Dave > > . > -- Regards, Zhen Lei 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 62D08C433EF for ; Wed, 29 Dec 2021 14:15:00 +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:Date: Message-ID:From:References:CC:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=3DgtB8c62GiRFTxI28Y61HWjH2ARr4K/Zr6dwiliEKk=; b=pTPLaiW4o1UDa5BTzOSkLU1fe3 eBcKfJo1LtnGV8VVb+Q/z6FwgbSbN5Hpzptbz6H1C/JVt+yuLa5kAGlJt4Mef0T2/O96xbAmLdHA8 If+jxdReYaI0SF4Lh+lRQaaZd3Ky/QrI8sEzCZF7APBV6mPOC787c/0ZsnfWaS2kjU5F4otOKud0U 5lRbldNwDrcZhMQiY72isog2D8AQUnEx/gjTo4YZ8ER9ckX1L7URVuzF1SxunVo/pGl3mHz7VNFEI +reHTyWcjUoutzmKZ79yCD7dZSH4t9PQl+AH95DTRi8+ClvUbsvyQ3qnZHqwJJ34+BHrw+zVL9Nq0 JQoMS54g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2Zhx-002uiP-0t; Wed, 29 Dec 2021 14:13:37 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n2Zhr-002ugP-N6; Wed, 29 Dec 2021 14:13:34 +0000 Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4JPCwF5HSczVhMD; Wed, 29 Dec 2021 22:10:05 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 29 Dec 2021 22:13:24 +0800 Received: from [10.174.178.55] (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 29 Dec 2021 22:13:22 +0800 Subject: Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code To: Dave Young , Borislav Petkov CC: Thomas Gleixner , Ingo Molnar , , "H . Peter Anvin" , , Baoquan He , Vivek Goyal , Eric Biederman , , Catalin Marinas , "Will Deacon" , , Rob Herring , Frank Rowand , , Jonathan Corbet , , Randy Dunlap , Feng Zhou , Kefeng Wang , "Chen Zhou" , John Donnelly References: <20211228132612.1860-1-thunder.leizhen@huawei.com> <20211228132612.1860-3-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <050a33f3-7a87-62ce-00bb-92b5d30915d1@huawei.com> Date: Wed, 29 Dec 2021 22:13:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211229_061332_138933_0A0A07DD X-CRM114-Status: GOOD ( 28.15 ) 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 2021/12/29 18:38, Dave Young wrote: > On 12/29/21 at 11:11am, Borislav Petkov wrote: >> On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote: >>> BTW, I would suggest to wait for reviewers to response (eg. one week at >>> least, or more due to the holidays) before updating another version >>> >>> Do not worry to miss the 5.17. I would say take it easy if it will >>> miss then let's just leave with it and continue to work on the future >>> improvements. I think one reason this issue takes too long time is that it was >>> discussed some time but no followup and later people need to warm up >>> again. Just keep it warm and continue to engage in the improvements, do >>> not hurry for the specific mainline release. >> >> Can you tell this to *all* patch submitters please? > > I appreciate you further explanation below to describe the situation. I do not > see how can I tell this to *all* submitters, but I am and I will try to do this > as far as I can. Maintainers and patch submitters, it would help for both > parties show sympathy with each other, some soft reminders will help > people to understand each other, especially for new comers. > >> >> I can't count the times where people simply hurry to send the new >> revision just to get it in the next kernel, and make silly mistakes >> while doing so. Or not think things straight and misdesign it all. >> >> And what this causes is the opposite of what they wanna achieve - pissed >> maintainers and ignored threads. I just hope the first 4 patches can be merged into v5.17. It seems to me that it is quite clear. Although the goal of the final stage is to modify function parse_crashkernel() according to the current opinion. But that's not a lightweight change after all. The final parse_crashkernel() change may take one version or two. In this process, it maybe OK to do a part of cleanup first. It's like someone who wants to buy a luxury car to commute to work six months later. He buys a cheap used car and sells it six months later. It sounds right to me, don't you think? >> >> And they all *know* that the next kernel is around the corner. So why >> the hell does it even matter when? Because all programmers should have confidence in the code they write. I have a new idea, and I'm free these days, so I updated v19. I can't rely on people telling me to take a step forward, then take a step forward. Otherwise, stand still. >> >> What most submitters fail to realize is, the moment your code hits >> upstream, it becomes the maintainers' problem and submitters can relax. Sorry, I'll make sure all the comments are collected and then send the next edition. >> >> But maintainers get to deal with this code forever. So after a while >> maintainers learn that they either accept ready code and it all just >> works or they make the mistake to take half-baked crap in and then they >> themselves get to clean it up and fix it. >> >> So maintainers learn quickly to push back. >> >> But it is annoying and it would help immensely if submitters would >> consider this and stop hurrying the code in but try to do a *good* job >> first, design-wise and code-wise by thinking hard about what they're >> trying to do. >> >> Yeah, things could be a lot simpler and easier - it only takes a little >> bit of effort... >> >> -- >> Regards/Gruss, >> Boris. >> >> https://people.kernel.org/tglx/notes-about-netiquette >> > > Thanks > Dave > > . > -- Regards, Zhen Lei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Subject: Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code References: <20211228132612.1860-1-thunder.leizhen@huawei.com> <20211228132612.1860-3-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: <050a33f3-7a87-62ce-00bb-92b5d30915d1@huawei.com> Date: Wed, 29 Dec 2021 22:13:11 +0800 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Dave Young , Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Baoquan He , 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 , John Donnelly On 2021/12/29 18:38, Dave Young wrote: > On 12/29/21 at 11:11am, Borislav Petkov wrote: >> On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote: >>> BTW, I would suggest to wait for reviewers to response (eg. one week at >>> least, or more due to the holidays) before updating another version >>> >>> Do not worry to miss the 5.17. I would say take it easy if it will >>> miss then let's just leave with it and continue to work on the future >>> improvements. I think one reason this issue takes too long time is that it was >>> discussed some time but no followup and later people need to warm up >>> again. Just keep it warm and continue to engage in the improvements, do >>> not hurry for the specific mainline release. >> >> Can you tell this to *all* patch submitters please? > > I appreciate you further explanation below to describe the situation. I do not > see how can I tell this to *all* submitters, but I am and I will try to do this > as far as I can. Maintainers and patch submitters, it would help for both > parties show sympathy with each other, some soft reminders will help > people to understand each other, especially for new comers. > >> >> I can't count the times where people simply hurry to send the new >> revision just to get it in the next kernel, and make silly mistakes >> while doing so. Or not think things straight and misdesign it all. >> >> And what this causes is the opposite of what they wanna achieve - pissed >> maintainers and ignored threads. I just hope the first 4 patches can be merged into v5.17. It seems to me that it is quite clear. Although the goal of the final stage is to modify function parse_crashkernel() according to the current opinion. But that's not a lightweight change after all. The final parse_crashkernel() change may take one version or two. In this process, it maybe OK to do a part of cleanup first. It's like someone who wants to buy a luxury car to commute to work six months later. He buys a cheap used car and sells it six months later. It sounds right to me, don't you think? >> >> And they all *know* that the next kernel is around the corner. So why >> the hell does it even matter when? Because all programmers should have confidence in the code they write. I have a new idea, and I'm free these days, so I updated v19. I can't rely on people telling me to take a step forward, then take a step forward. Otherwise, stand still. >> >> What most submitters fail to realize is, the moment your code hits >> upstream, it becomes the maintainers' problem and submitters can relax. Sorry, I'll make sure all the comments are collected and then send the next edition. >> >> But maintainers get to deal with this code forever. So after a while >> maintainers learn that they either accept ready code and it all just >> works or they make the mistake to take half-baked crap in and then they >> themselves get to clean it up and fix it. >> >> So maintainers learn quickly to push back. >> >> But it is annoying and it would help immensely if submitters would >> consider this and stop hurrying the code in but try to do a *good* job >> first, design-wise and code-wise by thinking hard about what they're >> trying to do. >> >> Yeah, things could be a lot simpler and easier - it only takes a little >> bit of effort... >> >> -- >> Regards/Gruss, >> Boris. >> >> https://people.kernel.org/tglx/notes-about-netiquette >> > > Thanks > Dave > > . > -- Regards, Zhen Lei _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec