From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CE112F290E for ; Sun, 17 May 2026 23:22:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779060126; cv=none; b=phSzJGopYaEQojKhNKOB0kL78siZQbTCk18xFtwDNmPORV12J2bbX1IgVwf22TLP6psjSJA1jF13DX/DCM+u7dW8InWvyeqGai6TxPFgRncJNDoqBdimBVNK4hmjaMHbWVlzMCjvcC/xKowAvIFPgFkyuQYZ8sjqf+kRr1OGfZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779060126; c=relaxed/simple; bh=WxHYqkzp7/G7ttQ4qio7ZbKdNhBkpwbp4SLfPYgRBs0=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=QSdJobILMxCeDz80IZLSyCf3iI25Ie07THmmutap+fzNQkkSsSPq724NhkosheQa/Ul746Dmm4lucdLovQ+7KLKGfcTAxIAjvVU94LLd0Xn9yfp5cpUOYzAfufq7dUuL6C+1OUe8rEattg1thxfkRP0R35rrpGUWDSkNCOjeJNk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JrmlvSCT; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JrmlvSCT" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-48d146705b4so17255715e9.3 for ; Sun, 17 May 2026 16:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779060123; x=1779664923; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=UBbUGCFqJiMRYfsl+eF9tbHmcztNauGUmlMdpL91Tl8=; b=JrmlvSCTzJ7VL4x1ZyI7ZLr3CfFzZqnIWOpug8xh/mvmbUCqSy7abXVfjTIMJ0J76l wA9Ad2oLh8LR014R7KsKvbkZ4Xz/i2ez+ND6yEPNbZGOESA3yKNQ4WjF7zTaPARM1Z2d u5TjwGQ8GJoEIv1RKzRe4fGax6Wjk/3LLeshQtd9qOH2LlGaoB6Nw4VADZU/crPuwHM5 UZ9fF7gwbM/HnRq4fG+Yes6NYEF83xNshonI3DYFYkIvrU8MPVcDMNS830Wxc4EeKN0f Hz+fWAYJNzHzEmEcQjgmaGmBJ5VrR1mK+MM2gkL3c160j3UcqqQVwLS20jxgLDQ+ilJQ 3qmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779060123; x=1779664923; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:sender :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UBbUGCFqJiMRYfsl+eF9tbHmcztNauGUmlMdpL91Tl8=; b=Z8+J8EHOsqr22jji4YRdk0MjfikwmhTlrIa8GE+wLFLkA3/e5gFtKLrGErU/Mj4gXO V7+o8Dmj5TC58vJMk9cLNLW5c0Xgj0UkVUknSe6L3rPqf0iT/AfhyD/uqLC9kNc7bwJG /R6bOJQwM2e3IM/ziUqliUQBoUCgS3VjIXpNua+7amzoLacJXi0U6Au5qOn6nBtWv6jK bwm0H35JmlcEzGRJnySR+hQ6x2ttjFe6SvASmagM1FZs0wZLiIxYUqod8PACTakF1Ila XT2b72cONW1x5yUF1/6ANXHeVEk6qA0gxi2u0o+5aE25OB0XjHvrYPWAizGjkcsoEBtH yXww== X-Forwarded-Encrypted: i=1; AFNElJ+NOLVUjvW8Fq+m+K6XOxwY9yLqd1fF01jhaI/gkOnvrjLtoWQyCoiLVXT1Iqwnb3icoBis0FyXZaqLLsc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw+aSt9GmCX44ifClSxWXb6HsUI8N+tUoZv3egccGapSR+E5Z2q ScXB8DNevu9QMe30sTlpQBgbGAbPQi9sY+Jv0nrCpvqCDBhEBawNWMOa X-Gm-Gg: Acq92OF8S8EzxkcQnymBBU1TfT2PSLuOrWnAe5UoSnKCTHDeFsYZ0PfDELSSV1wyd5y viYy6Cw3Akbb8Eo9ZnoXdme1g2kyNyv1oKRruh+MnY9zkkWoxJ+q2agtlS/DueEo0c0EvE6X7pA WxPkYOqS6x5FQsGxI9VEL1OxlXm7Q1sfpVteyLkhbmdUEyZC+qHSBwjnB0b1O2+HOhkkLn2qTj6 6Qr6hzUDjDXO78bDdf0HHaM48PsFd3CbhV+ZbCBMvJdvMXBBlnU28TRdNUaATwT6BUOaOXrukKS Svh8IBl47WsNcyhx7jme83vL3Hi+hX5u6qrbyHOqLTd46FdeUyW/+wBrwZI+Dh3vSv1+4pnsSnx /2AO4itOgj3HyP5VlOG4kShl9Ia8Vq1anI48YvAO5UkD4vop5V/qsgmrWzqA0d5Y3IZSHnM0qyU 89wPMsbtpnTmsIxd62yD4aaXPGw0xDPyzC2FQ9Kd0L231qdwEDSMupQJA= X-Received: by 2002:a05:600c:4a1a:b0:48a:592c:e655 with SMTP id 5b1f17b1804b1-48fe6325f25mr113675785e9.17.1779060123186; Sun, 17 May 2026 16:22:03 -0700 (PDT) Received: from [192.168.0.41] (bl21-200-180.dsl.telepac.pt. [2.82.200.180]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe4c8d39esm218924895e9.7.2026.05.17.16.22.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2026 16:22:02 -0700 (PDT) Sender: Julian Braha Message-ID: Date: Mon, 18 May 2026 00:21:55 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Julian Braha Subject: Re: [RFC v3 0/3] add kconfirm To: Demi Marie Obenour , nathan@kernel.org, nsc@kernel.org Cc: jani.nikula@linux.intel.com, akpm@linux-foundation.org, gary@garyguo.net, ljs@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, masahiroy@kernel.org, ojeda@kernel.org, corbet@lwn.net, qingfang.deng@linux.dev, yann.prono@telecomnancy.net, ej@inai.de, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org References: <20260516215354.449807-1-julianbraha@gmail.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/17/26 07:14, Demi Marie Obenour wrote: >> Hi all, >> >> kconfirm has shrunk a lot since v2! > Thanks for dropping so many of the dependencies! > > It might be able to shrink it further by using the existing C Kconfig > parser. This has the advantage that it ensures kconfirm and Kconfig > will interpret the Kconfig files the same way. I'm not sure if > that would be too much of a change. That's up to you. Hi Demi, I did look into the in-tree parser after your suggestion in v2. What I discovered was that this parser performs too much evaluation of the kconfig code during parsing, making it unsuitable for purposes of static analysis: The in-tree parser doesn't actually output a parse tree that we can traverse and analyze, which is how kconfirm currently works. Instead, semantic actions directly construct the symbol table *during parsing*, with that symbol table being different from ours. I think(?) this makes the overall process faster (which is great for real-world kernel builds), but for static analysis purposes, we really need to preserve as much of the underlying code as we can. For example, we don't even preprocess variables, because this allows us to analyze more regardless of the host and target. (Well, architecture is the one exception there because we need to resolve imports/"source".) I do want to point out that Yann, the author of kconfirm's parsing library (nom-kconfig) is CC'd on these RFCs and has done an awesome job of supporting the parser and kconfirm's usage of it. He also helped reduce the number of indirect dependencies pulled in by the parser following your feedback in RFC v2. - Julian Braha