Received: by 2002:a05:7412:3290:b0:fa:6e18:a558 with SMTP id ev16csp10747rdb; Thu, 25 Jan 2024 06:58:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IEk49Oor0IEdX/zuqxppSW3SN9zj8E1vF8v+Nm+K6ZmanlLk1KsqA5FlxR7coQgq2mjco0W X-Received: by 2002:a17:90a:6e42:b0:290:3b83:8897 with SMTP id s2-20020a17090a6e4200b002903b838897mr861192pjm.40.1706194698396; Thu, 25 Jan 2024 06:58:18 -0800 (PST) Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id e8-20020a17090a804800b002904c5068d2si1447217pjw.159.2024.01.25.06.58.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jan 2024 06:58:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-38744-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-38744-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-38744-linux.lists.archive=gmail.com@vger.kernel.org" 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id B7239289603 for ; Thu, 25 Jan 2024 14:48:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 381EC6E2D7; Thu, 25 Jan 2024 14:48:30 +0000 (UTC) Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) (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 69B5643AB5; Thu, 25 Jan 2024 14:48:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706194109; cv=none; b=Rbqk60+e+jqjdgZR53xYG88+El1Hp8L7x9E7P2AB4qqbpae+407RVoreRnkm+PUZqOKR+8FcvmXN3AhTgh0hCRyN9t/F9tLBMx3yjpBPxh1CRgOkl4d4bEwz6WO+iRqfFZHyThVAC4HAGFNsJAFcZKpQpwPXqAIcCZEMVsVwPhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706194109; c=relaxed/simple; bh=gC8yh7SbqhWBDjSrMZJJDyyUj2pIJgZ3BbEvjuSF48M=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LduQOZW8TKRyxba2yBTxS3QzZFrTWAFg2b+Vby2JDQ84BypOc5peSDMLNGPxFTuOvJbNfoqgVZFWqfa0INssFbXz7WmI4ff1DhJyYTUaG75+E1nyMtWbensrtwMLVAR6bs64v+XWs3f4aWJ+sygYRzf4u5dPTDxkaC3+VShnGD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.128.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-5ff7a098ab8so58593467b3.3; Thu, 25 Jan 2024 06:48:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706194102; x=1706798902; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Iy0vCAdx1ql9Q43DYTTM1zqch4I6/dCcp4gNza1bT10=; b=MlUQjOahfHyukU/KiAXNPtwIDA8tdSebmG4fcaLe8Gyhk7AYrS3ELsqD0pv/Wb5IVH vUGHKQXGJ3pqlVWNXY4Rg53/yp4d/arTtRklNn99td1D9lDUkbQw4XqvHDSkCxzNNENk a43ib70togdc0BUZQfaPpzfSzG/9ydw9hHNzfK9Krg+HkLG96ZlB4eALQZV7bDhZGh+y Qw6M/xmIQ8Ug/qmSPjkNvq9Kc8Gdl47W9A2jvKDdYJFfJ/Chc5AWf+gOZWhnmkmEUTWd lSyY0E0RPtMzWQAR/WNQK4nmenTX7rqPYo0wQw4afbJSz096xSSQzS3PnN8TyP0GbpLQ pTFA== X-Gm-Message-State: AOJu0YxU760tLSTq5OI23WKtcnUvVNF7zs0OysBDYU+6wzfgh/r7VzLG GKhAceYQTL0Q4jicoMryXh2Ajh/kFJy5S+FEhMLh8Qt/q59j3l6hu1CjzUNpEUU= X-Received: by 2002:a81:4fc9:0:b0:5f6:d6b9:9ea4 with SMTP id d192-20020a814fc9000000b005f6d6b99ea4mr997793ywb.79.1706194101830; Thu, 25 Jan 2024 06:48:21 -0800 (PST) Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com. [209.85.128.179]) by smtp.gmail.com with ESMTPSA id cp25-20020a05690c0e1900b00602ac0e698dsm689253ywb.68.2024.01.25.06.48.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jan 2024 06:48:21 -0800 (PST) Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-5ff88cbbcceso59188497b3.2; Thu, 25 Jan 2024 06:48:21 -0800 (PST) X-Received: by 2002:a81:8409:0:b0:5ff:d871:c76 with SMTP id u9-20020a818409000000b005ffd8710c76mr1047968ywf.34.1706194100880; Thu, 25 Jan 2024 06:48:20 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231125163559.824210-1-masahiroy@kernel.org> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 25 Jan 2024 15:48:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] kconfig: remove unneeded symbol_empty variable To: Masahiro Yamada Cc: Yoann Congal , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Linux-Renesas , Vegard Nossum Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yamada-san, On Wed, Jan 24, 2024 at 9:13=E2=80=AFPM Masahiro Yamada wrote: > On Wed, Jan 24, 2024 at 5:56=E2=80=AFPM Yoann Congal wrote: > > Le 24/01/2024 =C3=A0 09:09, Masahiro Yamada a =C3=A9crit : > > > On Wed, Jan 24, 2024 at 12:11=E2=80=AFAM Yoann Congal wrote: > > >> Le 23/01/2024 =C3=A0 13:54, Geert Uytterhoeven a =C3=A9crit : > > >>> On Sat, Nov 25, 2023 at 5:36=E2=80=AFPM Masahiro Yamada wrote: > > >>>> This is used only for initializing other variables. > > >>>> > > >>>> Use the empty string "". > > >>>> > > >>>> Please note newval.tri is unused for S_INT/HEX/STRING. > > >>>> > > >>>> Signed-off-by: Masahiro Yamada > > >>> > > >>> Thanks for your patch, which is now commit 4e244c10eab345a7 > > >>> ("kconfig: remove unneeded symbol_empty variable") in v6.8-rc1. > > >>> > > >>> When running "make _defconfig" with _defconfig an SMP > > >>> defconfig without explicit configuration of CONFIG_LOG_CPU_MAX_BUF_= SHIFT, > > >>> the aforementioned commit causes a change in the generated .config: > > >>> > > >>> -CONFIG_LOG_CPU_MAX_BUF_SHIFT=3D12 > > >>> +CONFIG_LOG_CPU_MAX_BUF_SHIFT=3D0 > > >>> > > >>> It looks like CONFIG_BASE_SMALL=3D0 is treated as a string instead = of > > >>> the integer number zero? > > >>> > > >>> init/Kconfig=3Dconfig LOG_CPU_MAX_BUF_SHIFT > > >>> init/Kconfig- int "CPU kernel log buffer size contribution (13 = =3D> 8 > > >>> KB, 17 =3D> 128KB)" > > >>> init/Kconfig- depends on SMP > > >>> init/Kconfig- range 0 21 > > >>> init/Kconfig: default 12 if !BASE_SMALL > > >>> init/Kconfig: default 0 if BASE_SMALL > > >>> > > >>> Note that reverting 4e244c10eab345a7 is not sufficient to fix the i= ssue. > > >>> Also reverting commit 6262afa10ef7cc8f ("kconfig: default to zero i= f > > >>> int/hex symbol lacks default property") does fix it. > > >> > > >> (Since I'd really like 6262afa10ef7cc8f ("kconfig: default to zero i= f int/hex symbol lacks default property") to stay, allow me to try to help) > > >> > > >> The problem is quite easy to reproduce: > > >> $ make x86_64_defconfig > > >> $ grep 'LOG_CPU_MAX_BUF_SHIFT\|BASE_SMALL\|BASE_FULL' .config > > >> CONFIG_LOG_CPU_MAX_BUF_SHIFT=3D0 > > >> CONFIG_BASE_FULL=3Dy > > >> CONFIG_BASE_SMALL=3D0 > > >> Here, CONFIG_LOG_CPU_MAX_BUF_SHIFT should be 12 not 0. > > >> For what it is worth, CONFIG_BASE_SMALL is defined as an int but is = only used as a bool : > > >> $ git grep BASE_SMALL > > >> arch/x86/include/asm/mpspec.h:#if CONFIG_BASE_SMALL =3D=3D 0 > > >> drivers/tty/vt/vc_screen.c:#define CON_BUF_SIZE (CONFIG_BASE_SMALL= ? 256 : PAGE_SIZE) > > >> include/linux/threads.h:#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL= ? 0x1000 : 0x8000) > > >> include/linux/threads.h:#define PID_MAX_LIMIT (CONFIG_BASE_SMALL ?= PAGE_SIZE * 8 : \ > > >> include/linux/udp.h:#define UDP_HTABLE_SIZE_MIN (CONFIG_BA= SE_SMALL ? 128 : 256) > > >> include/linux/xarray.h:#define XA_CHUNK_SHIFT (CONFIG_BA= SE_SMALL ? 4 : 6) > > >> init/Kconfig: default 12 if !BASE_SMALL > > >> init/Kconfig: default 0 if BASE_SMALL > > >> init/Kconfig:config BASE_SMALL > > >> kernel/futex/core.c:#if CONFIG_BASE_SMALL > > >> kernel/user.c:#define UIDHASH_BITS (CONFIG_BASE_SMALL ? 3 : 7= ) > > >> > > >> Maybe we should change CONFIG_BASE_SMALL to the bool type? > > > > My first test shows that switching CONFIG_BASE_SMALL to bool type does = fix the LOG_CPU_MAX_BUF_SHIFT default value. > > > > >> I'll poke around to see if I can understand why a int=3D"0" is true = for kconfig. > > > > Here's what I understood: > > To get the default value of LOG_CPU_MAX_BUF_SHIFT, kconfig calls sym_ge= t_default_prop(LOG_CPU_MAX_BUF_SHIFT) > > -> expr_calc_value("BASE_SMALL" as an expr) > > -> sym_calc_value(BASE_SMALL as a symbol) and returns sym->curr.tri > > > > But, if I understood correctly, sym_calc_value() does not set sym->curr= tri in case of a int type config. > > Right. > > The following will restore the original behavior. > > --- a/scripts/kconfig/symbol.c > +++ b/scripts/kconfig/symbol.c > @@ -349,12 +349,15 @@ void sym_calc_value(struct symbol *sym) > switch (sym->type) { > case S_INT: > newval.val =3D "0"; > + newval.tri =3D no; > break; > case S_HEX: > newval.val =3D "0x0"; > + newval.tri =3D no; > break; > case S_STRING: > newval.val =3D ""; > + newval.tri =3D no; > break; > case S_BOOLEAN: > case S_TRISTATE: Thank you, that works for me. Tested-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds