From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 6C1455680 for ; Mon, 7 Apr 2025 04:03:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743998620; cv=none; b=AXvvZNijEiBpFrdirTqEMixc532MtwT8iAeQ482Y543xzD7qI+15rFcObFpvut58YnUcAQ2wdNBQ3EZiV0a7Fn6zMNAWQKe/yxDt9VzExLVjk22SjGjfV+nJR8Cp2SMmxqJoFMsECn3F1462n6upzLIHkRaYoZqoGKAs8XKFUHw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743998620; c=relaxed/simple; bh=0zVp9p7hdlKATr7V9AzNIhmZQr8MUty7UFt1O8uro24=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VcgqAplZxeiLbtB4nS43ZDdvI5+W7ChgBflg/uAm5RPTwQKVaag6Wt8Gh+d6k/1St700JhIBT8L7653v3QJEdkZVEvp0jMaMmpIyznmP25YPhF7hP3G0gLR848u+NTtA9PB4xqs9htQChkJFhS7oBiT/Xz2sKFV8XmQ74/CPMbc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SrdtAcZE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SrdtAcZE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA84EC4CEDD; Mon, 7 Apr 2025 04:03:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743998619; bh=0zVp9p7hdlKATr7V9AzNIhmZQr8MUty7UFt1O8uro24=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SrdtAcZEhKR4qHavJFTQKdAcXjy0nhBb1yM6lCbeToqOKdy9ZT4333L3vKCgL0nSU 4YB1bHe4FU6dDm3HoVlcrbRXxHivajqlPwe5xGvFjMRbz52ncvP+9PrCyxgfFWyiHy Ieo08codohzIMnJ6mlWIPgjRAmCGhBUJXQlRGwGqrOLzqYvhpZ1fkQFezNRMHobMSV uMhfWE/DZTogrowc+cGIO7hjhcWa6DXR952VVriZex6YhfZBpfAN2hWvwLWa/s8Ysq ekqAb9aclBIqkrVcmAuuuVoY2cus13Y65I5fgvPLqTsPds38Cr9YMqraC44Xrzp5M9 zay1EMPaLoWdA== Date: Sun, 6 Apr 2025 21:03:38 -0700 From: Luis Chamberlain To: Daniel Gomez Cc: Masahiro Yamada , kdevops@lists.linux.dev, Daniel Gomez Subject: Re: [PATCH RFC 6/6] playbooks: add kconfig support Message-ID: References: <20250328-kconfig-env-with-ansible-v1-0-3231c0272457@samsung.com> <20250328-kconfig-env-with-ansible-v1-6-3231c0272457@samsung.com> Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Apr 04, 2025 at 10:33:07PM +0200, Daniel Gomez wrote: > On Tue, Apr 01, 2025 at 02:02:23PM +0100, Luis Chamberlain wrote: > > I think this usecase begs for a more basic form of 'make dynconfig', one > > which we always call. > > The only difference I see is that dynconfig generates a full Kconfig file, while > this one creates a fragment meant to be merged with an existing .config using > predefined Kconfig options. The relationship is a requirement to be generated before existing Kconfig files. The current kconfig fork maintained by linux-kdevops/kconfig [0] is maintained as a git subtree inside kdevops so to allow us to not require those odd git submodule strategy, ie, we maintain all history inside git and for users they just see the git tree one, not two. And so the common goal is to be able to try to avoid having to modify things which can make kconfig independent from Linux's version of kconfig. [0] https://github.com/linux-kdevops/kconfig > If I understood dynconfig correctly, then I agree with you. There's no reason > to declare these in the current Kconfig, unless we want to avoid generating them > every time. Then we'd need the fragment generation -> merge. Also, the fragment > generation is much simpler to generate than an entire Kconfig file. Indeed, > > If we're going to do that then we can kill two birds with one stone by > > having info-dynconfig and system-info-dynconfig, where the info-dynconfig > > consists of targets which won't require root or sudo. This is the part > > that might be useful to Masahiro, things like your compiler. Then the > > system-info-dynconfig target can be targets which require sudo or root. > > In that way, if a user does not want to have local playbooks run sudo > > they can simply describe their environment with a yaml file as input. > > This works with either option, since both are Ansible playbooks anyway. Sure. > > Nix users can also then just describe their system info and and be happy > > with calling qemu in a simple way, if they don't want libvirt to manage > > crap for you. > > I'm not sure about this. Can you ellaborate? OK so for example kdevops today aims to try infer tons of information from a user's system for libvirt uses. For debian based systems we go so far as having to use sudo to query the libvirt pools that exist. To many this is a security push they wish they could avoid. So an alternative to this is to instruct users by defaul to write down their systems's information about storage pool information. For nix users the same might apply so we do not repeat the same history. Instead of "requiring" to run sudo to check a system's virsh pool, we just go the other way with nix, and just have the user write down on a file manually where their virtpool stuff is. Only if they user a special command do we do the inference hoop which may require sudo. This sort of informaiton is needed before kconfig starts processign Kconfig files, and so we have two parts to this, a) new featuers b) existing features. The b) featuers are like the libvirt pool stuff. While an example of a) is nix OS suport. Luis