From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D21D8C001DF for ; Mon, 7 Aug 2023 19:31:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A5A06B0072; Mon, 7 Aug 2023 15:31:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 356286B0074; Mon, 7 Aug 2023 15:31:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 244796B0075; Mon, 7 Aug 2023 15:31:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 138EA6B0072 for ; Mon, 7 Aug 2023 15:31:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BD75E407CF for ; Mon, 7 Aug 2023 19:31:44 +0000 (UTC) X-FDA: 81098303328.22.1980CA4 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf14.hostedemail.com (Postfix) with ESMTP id 7C392100008 for ; Mon, 7 Aug 2023 19:31:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=XWXEoDjw; spf=pass (imf14.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.176 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691436702; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uLrESuDnsmXF0LnLVgvvKKzxJ74Ji/f7/0NisgyaeNY=; b=UT7cXZqDlvxSA5jM8ttB+Rwqeg45+t3uo+dJke5EK2jHZJ0B/sB29ZnFZ4QQr7+29gcB8W ec5AzRudf2XoBei8Yz8I1LYJRZtKbs4/Lc2EP6HjuK1/Tgzo0YJA72zTuM41+fApI8ouRV iQKirSOp6njKUtDIJG/IBqQKMOzVOJg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691436702; a=rsa-sha256; cv=none; b=HT6hFy+Yu/HFE5KkQPCaUoPoWQKIr0SrMhbTlF4kFazju2lgcHD9xGf2V3kGPxnKP+Lhws gb03AH5f62ZyqzjBRMGTdT9r845UbH3y0FbeQzRLvCfahKxhxlKNrJaq07cEbm7qL2tu0A Bcimut6el4VisQHf9WC3VIp97W9vQFw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=XWXEoDjw; spf=pass (imf14.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.176 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk; dmarc=none Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2b9fa64db41so76795591fa.1 for ; Mon, 07 Aug 2023 12:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; t=1691436700; x=1692041500; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uLrESuDnsmXF0LnLVgvvKKzxJ74Ji/f7/0NisgyaeNY=; b=XWXEoDjwIoxLdSnNQYBFSi1jX94xWwYgs4i714OjShNXUvW43/woTznr3IeaCP1HKu j7i6M7GAtPEl0AdM0vYHMdp7T+eY1avUVJNuM1YRuyBTsjdxorB0QYXqd1Mww7keuXhp 5PwS1WTmAuEkxJN7z9ApJON4oKGgEXGh2AoV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691436700; x=1692041500; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uLrESuDnsmXF0LnLVgvvKKzxJ74Ji/f7/0NisgyaeNY=; b=hcQnDOeseELaqVy7rfiTFjsTGPE3amUECqMQ/j30gbfRkwc5EEpJRFg69PANlAp75j m4aFUyziFOQUnX9+Qqbh1FoE39az16ZjajkVlRfcXBj3U7brd25aVrGFwr6jUd6ZmwY8 6T+2wPKExaQfFjwSXn2BSC40fYAbJSbdhLItkvsu0JCRIuM3E3fJDNDrwsmVKBN6b4Ge BlBaOkxT0cQt38rwetjJGex39v5nBiClYeDANcrdiJ2rQCraQ9Bk+AV3txBeAj/1WXmP 85KwBA8IdNw1R4neGTBGbttecH4AQnxX4XBayNBTOT8RBrqLq8iHCuS3+j++vp5l6i/l kMTA== X-Gm-Message-State: AOJu0YysIMXQ/ddS8JjqiQ8WL+6JisqIodbF0OwqTrnCVezHBwzBr7AQ gQI8ucXptHC5ldt8S1lPTFnufw== X-Google-Smtp-Source: AGHT+IFk3+ohzmOe6boF0ZZ2cAYTtOL4Ql9DEH7mbY5LEm16+hpE8IoUOk6elVbSrPdVAbdqOb6hUA== X-Received: by 2002:a05:6512:3696:b0:4fe:61f:3025 with SMTP id d22-20020a056512369600b004fe061f3025mr5912246lfs.61.1691436700291; Mon, 07 Aug 2023 12:31:40 -0700 (PDT) Received: from [192.168.1.128] (77.33.185.10.dhcp.fibianet.dk. [77.33.185.10]) by smtp.gmail.com with ESMTPSA id c18-20020aa7c752000000b0052228721f84sm5609359eds.77.2023.08.07.12.31.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Aug 2023 12:31:39 -0700 (PDT) Message-ID: Date: Mon, 7 Aug 2023 21:31:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends Content-Language: en-US, da To: Petr Mladek , Andy Shevchenko Cc: Marco Elver , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Steven Rostedt , Sergey Senozhatsky , Alexander Potapenko , Dmitry Vyukov , Andrew Morton References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com> <20230805175027.50029-3-andriy.shevchenko@linux.intel.com> From: Rasmus Villemoes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7C392100008 X-Rspam-User: X-Stat-Signature: b6znobu5qx8fxxka15xo78ux9zr8on7t X-Rspamd-Server: rspam03 X-HE-Tag: 1691436702-207970 X-HE-Meta: U2FsdGVkX1/HenAwSrpCcEyOTbitqi2HhQdLd2O3NYxDZR46KgcUXXS74/41sVUv58JYSu3mgdNbY28zTnyN7d65Zf+4Nhavo1HFh6ze4gArHLNNwMnJe9ai88utdoY0uGJRlNHuBm9+9Jt/reATAF9Qhguc4+PiqbFsWkGZbD2u6rxwm6vJsH6QO5YkutW63jQ2pyk5uN9mm21arYCeRKXHpjSV8V75z067r/wGm/u3wLUy1rvhIf5eU9D9PuN96nyqHTuCYTorvdFoe8Gtwx6po+efqBJROOwwDfVZ9QnR3d75OT9PQlfMk64wZAIanEBI4btLnXBlkg8jSWgdsKPJJdFKHUCcryx/Yq2+KAqttaNTY77mgaSw8I8E+MAUWb2i3vJecTsCj3xcjqI0lQA/Ch+meNihA6GYJ/DpAFFfTReoe3CZN/gLjbBkUfm2EFwiso8gL5ry07X56bz7CC/mqDsi5gvBDSqefiJ+MrxJUOtHkOmvF/thR7W/dM6zHyFvNJu0mEiaCOdqDn5AKIwW+Gly+pqyvdxrnO6M835JQZhcf45JOthsKp7eGI1iHMvl/MQeTf2BK0UP+BGeZsyt2E7R32nzyEEb1e9dD9fxUP2B6eySCwMfZHnioWmKWkhpCjfDa878LOhfWbRUY7l3EtOQ04GjC8qlPcHtKp0+Np1ulleNmyCjLPu1gbVEiyqNthiNPlhkzkiQsayVhwvt1F5Ar+mPoasu/XvwZahbe9ysBJxal15JWfuwv3ntzA+JglAcp8rAWOuXuSC/aG70elVWCZsPerpErpCRYGFaSual9E6+uf27v9A+Qy4u0/I/ai0pu5ZqQHRs3exEoFIz6wNkv+o7rDEPwk2G65CJLxDuspP2Obcd7veiXVjnoE5N303jrOMqgfqKOGkK9PENqOqfr0yo0KlVPQwzfEQqHv0EIL09YtjLV8w73WIXpnj+pCPBYIoyK3Xha1O kZypPjB5 FTFs/026BbdRAMBfEmxGMv+iVq+H28hwmxKwybspy9XxWzW/F34B4dBE9D2tMcmfJlhxZGHhwWt69884Uz8l97YBX6MlshKkO86K/b7HhV4eYHsIC8uYlofbtCUCEQrR47Qj/58QIU3G37P4N/WmkQaOddzprpTLcCp1YNaVYN+V+mblp99apQCxustFxdrkhaz+kvZ/ZhpVZajT+sUSthYAnYuvv2UXvRQVAcn/NL3y+ZkKwdRSS0BBynzTFDvHcFInq/UZ3BJtJ0X/R8O0c3f7Szx1bVsXZ2La6bbwpokdSDY9dsySO2Vad/874wuZhj15CKkyZ7A2GF7ua/PPEBNqWqmCsE2L1Au/20RK+7qXxfmsSZLOUKKu+iUU0irr9fohOfNyVIaRLIQ1QsT4G2pWkleqoWa2vb2Y6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 07/08/2023 17.03, Petr Mladek wrote: > I agree that kernel.h is not the right place. But are there any > numbers how much separate sprintf.h might safe? > > Maybe, we should not reinvent the wheel and get inspired by > userspace. > > sprintf() and friends are basic functions which most people know > from userspace. And it is pretty handy that the kernel variants > are are mostly compatible as well. > > IMHO, it might be handful when they are also included similar way > as in userspace. From my POV printk.h is like stdio.h. And we already > have include/linux/stdarg.h where the v*print*() function might > fit nicely. > > How does this sound, please? No, please. Let's have a separate header for the functions defined in vsprintf.c. We really need to trim our headers down to something more manageable, and stop including everything from everywhere just because $this little macro needs $that little inline function. I did https://wildmoose.dk/header-bloat/ many moons ago, I'm sure it looks even worse today. I also did some sparse-hackery to let it tell me which macros/functions/types were declared/defined in a given .h file, and then if some .c file included that .h file but didn't use any of those, the #include could go away. Sure, individually, moving the sprintf family out of kernel.h won't save much (and, of course, nothing at all initially when we're forced to add an include of that new header from kernel.h). But this technical debt has crept in over many years, it's not going away in one or two releases. And use of the sprintf family is very easy to grep for, so it's a good low-hanging fruit where we should be able to make everybody who needs one of them include the proper header, and then drop the include from kernel.h. Rasmus