Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2575498pxb; Thu, 3 Feb 2022 09:23:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJxzbxjRslQzxUJBWoavo1PJb5nfrjqvI0elOnnbpUAkRXlxJX+Fvpfq/GMMSx+CfNNkHeNp X-Received: by 2002:a17:902:d486:: with SMTP id c6mr35856884plg.133.1643909030370; Thu, 03 Feb 2022 09:23:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643909030; cv=none; d=google.com; s=arc-20160816; b=B+WWS50lNeCz96PkoBrr89+0th5w1wha5XTmQED0i2JLl8NxRLJp1P/jyi7ojkI1Aj A9rWrG3o24Uq4BeqjFdwRlDH4A/fQJ87FF/C0hI7GUJAx+ohY0pVopZ+SNWKgS3psUKE cGqumOT1FacCFHiTIJfsgdXMhNIUkcScEvUX8FrISGYAw2Ueq2AzEpRM/S8Sa4pafku6 CT7IvLceIyYNmQdSXSkbf0HQoJ6oDYxr2DofJ5qU1R68hc+1j824U42LiH+BJbQpSTvL nMQsNcwsE0dNWssNhocQY/NAVU6rvC7ujz/nRHD3K/wBvl87r1IPwyLUJOjrHaLagNai XChw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=tEbNuUaeESsbucNNxWCSNAVotbkzKzn/eOuBs8ycKg0=; b=YNOj+LdEK87SjiNIeojJ6uo22GwHgxBaDdvswBAQZOL9PTHDlmZxv3+9QWSFp/nw66 tdsGa8lU9/DGylAGKDWzQB3lNCizRYX04y5C3iRjstF9czS3DpG9/1YhmAXHu4HjRjHP v+1XTDYz4HQ7LQdCiFkcFsGhKa9fK2sGsXVYgWdT4fD5tyqS8x7G1OzqTFFbPPxYsF0t R1BIz2uE5plxHlv5tkkEF6u7AJ+MCBwmbT0mPhMyI3K7RZ0fCemJCAgxjiBScwWrQE5k Cv/jITrxGW0W0Q6W/xeWeFQmjlbjDAZ2suYdpHOP1xE+b2wmwzoSSda03RUPMXI03cWa RGMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=IMnepHfd; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=ttdkmFz2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i189si15955690pge.114.2022.02.03.09.23.38; Thu, 03 Feb 2022 09:23:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=IMnepHfd; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=ttdkmFz2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348488AbiBCAVy (ORCPT + 99 others); Wed, 2 Feb 2022 19:21:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232227AbiBCAVw (ORCPT ); Wed, 2 Feb 2022 19:21:52 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5810BC061714; Wed, 2 Feb 2022 16:21:52 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1643847707; 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: in-reply-to:in-reply-to:references:references; bh=tEbNuUaeESsbucNNxWCSNAVotbkzKzn/eOuBs8ycKg0=; b=IMnepHfdalRiGysYHX7LfnKshsG5zdFcG6DYWr7nwEuByFG9qxqYnv7rrSDQFRC54UiNUt mvd1AXERhe64nvhyFI+ahmenkr9hK0A0S8+64Raq7PQDtsjPIROFK0lYgqfFvbW9XkwbzQ BhMSpdcO3/6IcqzlF0u28L2YwIuOYeqxpK6ahSaibD9qPADHldgwKjahrWIVFR2gSuKLiV WT1GHAPXrzjgax1zfOLrqLJxECVk8jjtqTisPcy8vhXZQcCkyvJ150+KipQMIf82n8rtN/ CpmCj07Ipp4wybFpiwExkRYBNlKQzP+Dnq1YMagiIQFi75Ml3NqU33WnO8wYnw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1643847707; 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: in-reply-to:in-reply-to:references:references; bh=tEbNuUaeESsbucNNxWCSNAVotbkzKzn/eOuBs8ycKg0=; b=ttdkmFz2pO6CB9U65vVYu3aA5mjj/UcMMXrDKsiJED0oOMRdTFbbHgc+Cs8YeGKvx0hHgw z/cTrL+kqOiYo5Aw== To: tangmeng , mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, john.stultz@linaro.org, sboyd@kernel.org Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [PATCH v5] kernel/time: move timer sysctls to its own file In-Reply-To: <20220131102214.2284-1-tangmeng@uniontech.com> References: <20220131102214.2284-1-tangmeng@uniontech.com> Date: Thu, 03 Feb 2022 01:21:46 +0100 Message-ID: <87wnicssth.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tangmeng, On Mon, Jan 31 2022 at 18:22, tangmeng wrote: > kernel/sysctl.c is a kitchen sink where everyone leaves their dirty > dishes, this makes it very difficult to maintain. Sorry. That's just a lame argument. What exactly is hard to maintain on that file? A large table of ifdeffed sysctl entries which changes once in a blue moon is hardly a maintenance problem. Aside of that, sysctl.c is a very conveniant way to look up the zoo of sysctls which you now spread out all over the source tree. So you really need to come up with a technical and sensical explanation for this change. > To help with this maintenance let's start by moving sysctls to places > where they actually belong. The proc sysctl maintainers do not want to > know what sysctl knobs you wish to add for your own piece of code, we > just care about the core logic. In other words, invite everyone to add random sysctls as they see fit w/o a central review authority. That's not an improvement at all. Quite the contrary. That aside, I'm tired of this because this is now at V5 and you still failed to fix the fallout reported by the 0-day infrastructure vs. this part of the patch: > +static int __init timer_sysctl_init(void) > +{ > + register_sysctl_init("kernel", timer_sysctl); > + return 0; > +} kernel/time/timer.c: In function 'timer_sysctl_init': >> kernel/time/timer.c:284:9: error: implicit declaration of function 'register_sysctl_init'; did you mean 'timer_sysctl_init'? [-Werror=implicit-function-declaration] 284 | register_sysctl_init("kernel", timer_sysctl); | ^~~~~~~~~~~~~~~~~~~~ It's pretty damned obvious why this fails to compile and the 0-day reports have all the information you need to reproduce and address this, but you prefer to ignore it and just resend yet another incarnation. Feel free to ignore these reports, but then please do not be surprised when I ignore your patches. Our development process is well documented and it's not subject to your personal interpretation. Thanks, tglx