From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 239EB311975 for ; Wed, 25 Mar 2026 18:21:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774462903; cv=none; b=FJgZH3O5m2gp1YPcgvHxG02IRets9y9vvoM43ChCfc+E9ECJyDwscMkP+FYIZfNd/3e3ge14pje+Eaza0rU3iz4KKWjJSjHzOR8s612Dbbjb68YjN4El0du8MI0CxN6lpGT34/boa171relqvarVVqYMH9vpKGtbmgabwikutN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774462903; c=relaxed/simple; bh=j/8HBXogBTXRmiBt5urwYz9i/Dv3TR6wKTxNqfUvbxQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=R1+ycbCutaTyvd6Y1FINbYnxXCY13qkcdZmE1ma8wzPacjhDrz2EJpqgle1XiZyEr53FBQ6VkAGLS8c1V6bbdXq+w/a7Ne8QvKVU4mCnSO2LdzHYK16h2cbuey9uiiX9+2uVYjsz89QDGTr+p14359h6yGBk+/YIK1+Qx+52SFE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=tsAbB3WN; arc=none smtp.client-ip=95.215.58.187 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="tsAbB3WN" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774462900; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vOx/bmCPLljACX+p/sN22wPdMKIM8WABMeOEwamW+vs=; b=tsAbB3WNQh8uh9EGdaSTCtN73fwAlsVPcHIA78iPTcq5OoAIFID1AULMZlSscfZnYz1JWr rI3v3JQelL+E8iIvGThXsPM2rYy9/d7tsrcfk4DXfMy/MziIqct4X9ZHG41y6S3XfLy0HN 2dszchcrfLUSP86eX8qqpSDnqs/eNBs= Date: Thu, 26 Mar 2026 02:21:20 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH v4 0/2] sysctl: refactor ctl_table initialization To: Joel Granados Cc: linux-kernel@vger.kernel.org References: Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Wen Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 3/19/26 22:32, Joel Granados wrote: > On Thu, Mar 19, 2026 at 03:12:04PM +0100, Joel Granados wrote: >> Hey Wen >> >> Comments inline >> >> On Wed, Mar 18, 2026 at 01:36:13AM +0800, wen.yang@linux.dev wrote: >>> From: Wen Yang >>> >>> The main motivation for this series is to avoid treewide patch series. >>> Historically, changes to how struct ctl_table entries are initialized >>> (e.g. removing the child field, const-qualifying ctl_table) required >>> touching hundreds of files across all subsystems. Such series require >>> the attention of many maintainers, sometimes need to be pulled into >>> mainline in a special way, and create lots of unnecessary churn. >> LGTM: Clear motivation. >> >>> >>> By introducing a family of CTLTBL_ENTRY_XXX() helper macros in >>> , any future structural changes to struct ctl_table can >>> be handled in one place — the macro definition — without requiring a >>> treewide sweep of all callers. Individual subsystem maintainers can also >>> migrate their sysctl tables to use the macros at their own pace. >> I think this paragraph is redundant; I would remove it. And just add >> "This will all go away with the CTLTBL_ENTRY_XXX helper macros" as the >> last sentence in the first paragraph. >> >> Migration strategy >> ================== >> You touched on this when you mentioned that the maintainers can migrate >> to the new macro at their pace. In my experience this will never happen >> if you give the responsibility to the subsys maintainers (They are busy >> with other matters). I think the more successful strategy is to lead the >> conversion from sysctl. >> >>> >>> Based on discussion and suggestions from: >>> [1] https://sysctl-dev-rtd.readthedocs.io/en/latest/notes/ctltable_entry_macro.html#table-entry-macro >>> [2] https://lore.kernel.org/all/psot4oeauxi3yyj2w4ajm3tfgtcsvao4rhv5sgd5s6ymmjgojk@p3vrj3qluban/ >>> >>> This series: >>> 1. Introduces the CTLTBL_ENTRY_XXX() macros in include/linux/sysctl.h, >>> allowing callers to initialize struct ctl_table entries indirectly >>> via the macro instead of assigning each field directly. The macros >>> use _Generic() for automatic type detection and proc_handler >>> selection, provide smart defaults (auto address-of, auto maxlen via >>> sizeof), and include compile-time validation of name, mode, and >>> handler. >>> 2. Converts kernel/sysctl-test.c to use the new macros as a >>> demonstration, replacing direct struct ctl_table field assignments >>> with CTLTBL_ENTRY_XXX() calls. Four new tests are added to cover the >>> previously untested variants (CTLTBL_ENTRY_V, VN, VNM, VNMH), bringing >>> the total to 16 passing tests. >>> >>> --- >>> Changes in v4: >>> - Fix Wpointer-type-mismatch warnings detected by lkp: >>> https://lore.kernel.org/oe-kbuild-all/202603050724.SZxrEyyu-lkp@intel.com/ >>> >>> Changes in v3: >>> - replace the unique macro with "capital letter approach" >>> - reduce the name further >>> https://lore.kernel.org/all/rn4rsazh7kxf5byq65vw2phyqgzvwm3scczu3l5h2r4aqit2r6@znlpb24z2zuo/ >>> >>> Changes in v2: >>> - add lvalue check, handler type check, etc. >>> https://lore.kernel.org/all/xptwb3uwbzposd4xf7khj52ifv4tchcjdgllhv7aabi6d7wgef@2msurl564v53/ >>> >>> Wen Yang (2): >>> sysctl: introduce CTLTBL_ENTRY_XXX() helper macros >>> sysctl: convert kernel/sysctl-test.c to use CTLTBL_ENTRY_XXX() >>> >>> include/linux/sysctl.h | 294 +++++++++++++++++++++++++++++++++++++++++ >>> kernel/sysctl-test.c | 240 +++++++++++++++++++-------------- >>> kernel/sysctl.c | 2 + >>> 3 files changed, 437 insertions(+), 99 deletions(-) >>> >>> -- >>> 2.25.1 >>> >> >> Best >> >> -- >> >> Joel Granados > > > For your next version I would keep it as an RFC but include a more > targeted audience. Add the Kees Cook to the "To:" and > add linux-fsdevel@vger.kernel.org to the "Cc". This will hopefully get > some feedback and we can take it from there. I can nudge the new RFC if > it does not get any initial traction. > Thank you for your kind instruction. We will revise it based on your suggestions and send v5 soon. -- Best wishes, Wen