Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7345541rdb; Wed, 3 Jan 2024 12:37:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IEzj6DqEbX4WjnlGPccCtvQqpm7xiNFBwvfZCfGX6fJsHFNadUhDt7n6pEzDB/R0wyEj0CO X-Received: by 2002:a50:8e56:0:b0:553:29ef:4f86 with SMTP id 22-20020a508e56000000b0055329ef4f86mr12966770edx.69.1704314226569; Wed, 03 Jan 2024 12:37:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704314226; cv=none; d=google.com; s=arc-20160816; b=CTtI5HlBpdKWpkUDmq8URNVsAXw8RlPzb3KLusKqNg4eLiAZE95X0k0blT1LJ3ezO7 o5sxOmyaXBqzUl6ccWFoCV6xBhw4dAQ7bW3Kf7N/nOlqxcmbCapIK6tl95DfysDwKZRZ 2Cug136mj3F0kp1wUYdP/zyuQbKRMi2PlHhoCkXg67ZB/JQl7A+gq+19z3dViMfciCcz UDRrDJGTNjs8OA5VWPwLMW1ieIW+XJxkU6AbTD+LJO+1LUNYWJ71Lnm33S9tVJvUtVUu QFva3u8m41Xu08EoYxA6U29KTeBztX4rJHs01y6raOXZsYbxpG7P1fjOeARHBeQ76XB9 GrzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :message-id:date:references:in-reply-to:subject:cc:to:from :dkim-signature:dkim-filter; bh=H7TXJw6dQEQvwm1EXNrX3GZKv2TSI8Mhwx5sNEHJLR4=; fh=iQiUTHFvTQQp2dDLFJyFEGQU0up3kyC8hReTjFi668s=; b=weL6fvyZgActY02Vwu91rl3MdM+cdTSXDodVzdH8SXz5Bjjco0KqryEzV6PEqTAoSe 8L+mm+dj/F7pJImqFBznQCItNAd79FtMBlp6bvZCDBDfEGXcvfiHje1YZuaqHqrgUT3m OaH5tN+BfndiaT4dKQYXXfE4s8E1CjOqN7pmRPXgCWZVWeX2P/8YMbIWpVKPpFzdXzk0 t/txDCTJPjNSBDblvzCgZfVM7pqCRBBQ5J1Dofla4O8kKou4r7DS8EKo69z/ZNtOtVa4 iuBVtSF4EJ2x7kxt0yBg06zialrFvLWHFAqxHoGzdhvrMbx9Qm4W3O7eBJgiI3TqV5Oi ahvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=j5PHTXdn; spf=pass (google.com: domain of linux-kernel+bounces-15991-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15991-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lwn.net Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id y9-20020a056402358900b00554b2c32cbasi9563954edc.97.2024.01.03.12.36.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 12:37:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15991-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@lwn.net header.s=20201203 header.b=j5PHTXdn; spf=pass (google.com: domain of linux-kernel+bounces-15991-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15991-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lwn.net Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 59E321F21FD1 for ; Wed, 3 Jan 2024 20:36:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1B9721D692; Wed, 3 Jan 2024 20:36:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lwn.net header.i=@lwn.net header.b="j5PHTXdn" X-Original-To: linux-kernel@vger.kernel.org Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) (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 CA5431D681; Wed, 3 Jan 2024 20:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lwn.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lwn.net Received: from localhost (unknown [IPv6:2601:280:5e00:7e19::646]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 980251C33; Wed, 3 Jan 2024 20:30:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net 980251C33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1704313821; bh=H7TXJw6dQEQvwm1EXNrX3GZKv2TSI8Mhwx5sNEHJLR4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=j5PHTXdn/jFPsLKcWbOYVlr9Up5jR46UoVj4ua9y4vonIgCq3Nm8B1dnaQSma2k71 5bqE0ERM4uQJHFl6z87L42G53KHAw+XrEZKvrYv+PJRkbfzz7Bf8DQt+wWWMzOjinB xyGiz7jkuU8I7/igYCT9umlCSLF7FlNhZmRPeFH+rLf1ATCKmsjkWwstu/oDA6VoDL h7snkKDDQ2Qy924FbRPoeJ6PCwKSo1YH5mFDaKpnlCY34G8Wwd/Sa3ANflo/nRqECV L+lpRthRpAHpwm6FDHURXjDdtXa75vcFs35J9Uzs+dyW5wn3RyVQ7ebUrDpSXATDDr c/I930ZzwFdqA== From: Jonathan Corbet To: Randy Dunlap , linux-kernel@vger.kernel.org Cc: Randy Dunlap , Thomas Gleixner , x86@kernel.org, linux-doc@vger.kernel.org Subject: Re: [RFC PATCH] kernel-doc: handle X86 DEFINE_IDTENTRY() variants In-Reply-To: <20240102061700.3807-1-rdunlap@infradead.org> References: <20240102061700.3807-1-rdunlap@infradead.org> Date: Wed, 03 Jan 2024 13:30:20 -0700 Message-ID: <87il4a9n37.fsf@meer.lwn.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Randy Dunlap writes: > Teach scripts/kernel-doc to handle the various DEFINE_IDTENTRY*() flavors. > > This corrects 2 kernel-doc warnings: > > arch/x86/entry/common.c:211: warning: expecting prototype for int80_emulation(). Prototype was for DEFINE_IDTENTRY_RAW() instead > > arch/x86/kernel/apic/apic.c:2170: warning: expecting prototype for spurious_interrupt(). Prototype was for DEFINE_IDTENTRY_IRQ() instead > > The script uses 'uname -m' to determine if it is running on i386 or x86_64 > or something else. It also uses "ARCH=" in the environment variables > to allow for overriding the processed ARCH. > > Alternatively, we could remove the "/**" kernel-doc markers from those > 2 functions. There are 60 uses of DEFINE_IDTENTRY*() that I see and > only 2 of them have kernel-doc comments. So I feel like I'm missing something here; the docs build should be the same regardless of the architecture it's running on, right? So why do we need architecture checks in kernel-doc? Honestly, it might be better to just remove the kerneldoc comments rather than add this much more complexity. Thanks, jon