Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1685525rwe; Fri, 2 Sep 2022 01:54:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR5em8P/yPWmkfKT2gnmR4zLXFB9IvUX3hNqMxV+S/AAENvb3QBXiaGxD5Nc5ruuk+UOm17f X-Received: by 2002:a05:6402:22d0:b0:447:9c9a:f6b9 with SMTP id dm16-20020a05640222d000b004479c9af6b9mr33196207edb.296.1662108848681; Fri, 02 Sep 2022 01:54:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662108848; cv=none; d=google.com; s=arc-20160816; b=Pwg9irwdWAU60VjzvVRyXJDP2P+0WCIaqhR0t8csR9nfonJ6yps992fEl4W+0G7OOk w0tjWReW1nc6bSXeWgMprtgRvqalkEfnXdKXFDMXZfGTrvsvkuMmfvKKgyCZLzZDlIzF Cs7NfFMlSb1LEKSyIJeKmm22sUCykipP5asImHDH1G94ylo4/I2nRus8zEzgcoWgmoyq zCIjv/rIKv8LNX8/zJQjYEH0Ape9w/It0SYRBH8a9L+Z2odc/p6FL2o9dQti3L5KV5KV 5jj5he5jjm5dF6RmU6VgZ2rOIeULzCMDAPqpsaMyXN4CsZoZc594t3/ZPets8dq7uv9n Mc4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=1i7j/swt16X4UVbcDcaXz040PkNBu1+BieE4zMZT53M=; b=aLVdAu4om+pTr+Yol1xImrjFGUmMMu3JtXL4cX5gTHFR/0uCoMoSSjc2TyzFFjtCRM tm8JZNxa7K7Lhr+dQuidcu/MNq+4a0B6NMLjwqG0PDnnznBuYbzgpmYdh3EioLAFozln v9oO99NhcoRVrB/lkCtPT1keapoWDq2oVhw+8iX5DrQzyBp1DRGMic44SwIYmByuIT/0 KZ4hufIYoT92ivN2WGARREWHELD1cfdXWHqS/mGk68MxvMaL/gbNozZ7/jxH/oazJI/U oDkFmVYhakq6t145yAhQEesOlZi4RQ/6ZuTWRufOw/w9WAExWW9TFxIzLyYjLyGyoCol yjqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=R7m0JXjI; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hg3-20020a1709072cc300b007417374cfafsi1260408ejc.844.2022.09.02.01.53.18; Fri, 02 Sep 2022 01:54:08 -0700 (PDT) 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=@gmail.com header.s=20210112 header.b=R7m0JXjI; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236086AbiIBIv3 (ORCPT + 99 others); Fri, 2 Sep 2022 04:51:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236107AbiIBIvN (ORCPT ); Fri, 2 Sep 2022 04:51:13 -0400 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14D857B1D6; Fri, 2 Sep 2022 01:50:33 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id nc14so2486295ejc.4; Fri, 02 Sep 2022 01:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date; bh=1i7j/swt16X4UVbcDcaXz040PkNBu1+BieE4zMZT53M=; b=R7m0JXjIGgvtEMkwEzdKz/sEvLuNbFj0OElMpeGlnRSJe0a0zDy/n8DwmFtuJeOqPE n51SJqi9JZ11It7JZBV3m0HZjRWAPkZc9Bp7IBPC8Iwct65MAk8Mch9CZKLsnd5bNIGT SHtpV/k2fC5kZ5KVOVbQydAbm9R3EhE/9/tO1oMumWtHbQ3qo0HOfpHGHQrgtf6GWTgL /gtPKGfgCfgbfUx6XaIc8C7YeQhlL+uYHZ0nbudsyt4kPNF9ysvmcCE8ESSfh1VsiHIj YpqDYur4SqoLXO/p/5iUXB1CJxe/FaYRWLWa/SALL4WKyAW0NCKFnCrA99jZQUb1QPdg f7VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date; bh=1i7j/swt16X4UVbcDcaXz040PkNBu1+BieE4zMZT53M=; b=I7WV7GVJS+FT7B7SKszEc/G2gcAwlxe2cVygUe1JforMGmzAVzjE314ERRK9xuOQUy gxRq6K3cue+j1skvA9jFcKdk20FIIkhclnhlqguTC8X2UxW1Gg1eF2rZMJ+6LXLMZX25 Gez0b68VPVoDg5Lpom4qQ2aWxF7t+ODkCeKjSyNYkrDROgyo8jsrKEB3MBmhwbcngoe+ HXHY2INTddfpk2jJFJzfuro7KRKCPBFGqcbMrZd0f66N1lQ5VtJaOti+NnTBHCvoFCAY 6Swnarhuyt70pPgQ062RJUJgO8gUpL+vN8KfA2LWYkx/2KWtMTrpnUoXGJ5+j1xx63VE YjAQ== X-Gm-Message-State: ACgBeo2L+v/egHf1pvcU9fi3CstAmioZjUtkpL8kkrDorBiyAVNTsxEK CNR2DTfggOojUz12rWGIbVY= X-Received: by 2002:a17:907:a049:b0:73d:c6c9:5263 with SMTP id gz9-20020a170907a04900b0073dc6c95263mr26015814ejc.563.1662108631627; Fri, 02 Sep 2022 01:50:31 -0700 (PDT) Received: from gmail.com (1F2EF751.nat.pool.telekom.hu. [31.46.247.81]) by smtp.gmail.com with ESMTPSA id cb26-20020a0564020b7a00b0043d1a9f6e4asm1016225edb.9.2022.09.02.01.50.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Sep 2022 01:50:30 -0700 (PDT) Sender: Ingo Molnar Date: Fri, 2 Sep 2022 10:50:28 +0200 From: Ingo Molnar To: Nathan Chancellor , Masahiro Yamada , linux-kbuild@vger.kernel.org Cc: Linus Torvalds , Borislav Petkov , Linux Kernel Mailing List , Peter Zijlstra , Will Deacon , Waiman Long , Boqun Feng , Thomas Gleixner , Andrew Morton , Sebastian Andrzej Siewior Subject: Re: [PATCH] x86/config: Make the x86 defconfigs a bit more usable Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Nathan Chancellor wrote: > On Sun, Mar 27, 2022 at 09:03:14PM +0200, Ingo Molnar wrote: > > Yeah, good catch! ... > > > > I use defconfigs by explicitly adding in the architecture: > > > > kepler:~/tip> make ARCH=i386 defconfig > > > > kepler:~/tip> kconfig-arch > > i386 > > > > ... so never I noticed this bug. > > Ah, good point! > > > I fixed this in the latest version (attached). > > > > Arguably 'make ARCH=i386 savedefconfig' should preserve this, so that > > refreshing defconfigs on bi-arch architectures is idempotent, but that's no > > excuse to regress the existing defconfig behavior. > > Hmmm, I thought that it would, but I think the behavior of savedefconfig > is actually correct with regards to how it handles CONFIG_64BIT in the > presence of an explicit ARCH value, based on how CONFIG_64BIT is > defined: > > config 64BIT > bool "64-bit kernel" if "$(ARCH)" = "x86" > default "$(ARCH)" != "i386" > help > Say yes to build a 64-bit kernel - formerly known as x86_64 > Say no to build a 32-bit kernel - formerly known as i386 > > As the default is no when ARCH == i386 and there is no prompt in that > situation, "# CONFIG_64BIT is not set" gets dropped, as that is the > default. Using savedefconfig without the ARCH variable would do the > right thing. > > I tried playing around with these Kconfig symbols to see if I could get > something that would work for savedefconfig with or without ARCH, but I > could not really come up with anything. I did not try super hard though, > it might still be possible. Unfortunately, even without the ARCH=i386 'make savedefconfig' doesn't seem to be doing the right thing & is dropping the '# CONFIG_64BIT is not set' line: kepler:~/tip> make ARCH=i386 defconfig *** Default configuration is based on 'i386_defconfig' # # configuration written to .config # kepler:~/tip> make savedefconfig kepler:~/tip> diff -up arch/x86/configs/i386_defconfig defconfig --- arch/x86/configs/i386_defconfig 2022-09-02 10:45:43.117430882 +0200 +++ defconfig 2022-09-02 10:46:56.663864901 +0200 @@ -282,4 +282,3 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_BOOT_PARAMS=y CONFIG_UNWINDER_FRAME_POINTER=y -# CONFIG_64BIT is not set kepler:~/tip> This is annoying in that every time I modify the i386 defconfig and use 'make savedefconfig', I have to manually revert that change ... This reduces the usability of 'make savedefconfig' quite a bit. Maybe Masahiro-san can tell me how I'm doing this wrong? Thanks, Ingo