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 12721C001B0 for ; Thu, 10 Aug 2023 09:09:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 46BD56B0075; Thu, 10 Aug 2023 05:09:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41BA36B0078; Thu, 10 Aug 2023 05:09:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E3A56B007B; Thu, 10 Aug 2023 05:09:27 -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 20B7D6B0075 for ; Thu, 10 Aug 2023 05:09:27 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D61DDA0190 for ; Thu, 10 Aug 2023 09:09:26 +0000 (UTC) X-FDA: 81107621532.23.D75174A Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf11.hostedemail.com (Postfix) with ESMTP id C7CED40013 for ; Thu, 10 Aug 2023 09:09:24 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=HuwTeero; spf=pass (imf11.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.169 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691658565; a=rsa-sha256; cv=none; b=AkM5PXSh30wiHnCoMMWYk3HXlqmrG+AKxHG4FtaqQ0MDnzTRrwljNFNiVNgGUUtPMBN3xJ N8ltmEcZZ8IgaFUuZ9PJI9yBS2Bvzt1+jXHOZvA5CxGvHs0D84c8OBT0xBb5tUp2P+Ez7D PrX4MuLsXrPPuqRL9RpyCbLlgRVM0r8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=HuwTeero; spf=pass (imf11.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.169 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=1691658565; 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=IAppfDze+b0mlNksRhfLMmF8syWDm1cJ2oYz5chDViw=; b=HmqDbrchrw7sQ3HNpoQ1kfc0QQ42roDzCCa8RKGrAbEy7I/okBUpikYWtXUlT6Tii80QE8 KefeBEowuLT7b/laSYzlgIhlqwuqdZkY9FHeYiKa4A1XrjxmcuR5Bn6PpPIw4sXj94ne7U I65MRI/Ci5qVibuEDFmFRCuckrcAddg= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2b703a0453fso10463781fa.3 for ; Thu, 10 Aug 2023 02:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; t=1691658563; x=1692263363; 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=IAppfDze+b0mlNksRhfLMmF8syWDm1cJ2oYz5chDViw=; b=HuwTeeroDJ144764rUZdAJTutbWPyr1EQqYweC8pKf4+Rg2BTcj/BJbC24+eni6mAk 5idUuBHZ1vUCEFc0Juw2K1QIJbVBUfEC3lrqmG3fR4utT5q3xejsWOj1hYt5pmknt4Sb YCid8dLFG4e0swHy+K5AoNMQIR1DhanTuupmk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691658563; x=1692263363; 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=IAppfDze+b0mlNksRhfLMmF8syWDm1cJ2oYz5chDViw=; b=l0bMCfMvQilVm+hUlo/kP90e0sKYl9xFRtm3Bwl/aZDnmb7etD0QCgj177RHlyYF2E 4p5YgeyV/PLMAiYIJUukw3CslrgDjlou+aCBKsP064qkBH04dCwdQIcaZoBCEV6D2s2S 5ZN+NNqqHcnW/lPN6+MEyVXHBeHHvxPq/5Ys+ntrYIBHuWKNUVlV0PGXfmZr7nOT+e4+ BMJ+PZh83ZQ9t4RYVLXknw5wk2rjltBZYgGXhQMUPIz0T957YuGJ2JoaK9FylOALPeJ3 wYwZURVJOmvyImnxmX8DiUJmcUTR0ptK8KtoH0QxguOUC0ZnaS5Od7lN2O4eVljpgeEN c+MA== X-Gm-Message-State: AOJu0YxIWKcwm2uSEkYXn6m1PmbQ+L8sZ7vS9It5lstkCL1B7IcezPWC iBvE9xmHzPhJ4mw6IAM9UDdGCA== X-Google-Smtp-Source: AGHT+IHVxHBRMDm6vKLkC2APmFhnCS1PrzaDVfdNO9/9mK9FQAj2LNwbF7TYoRq5+aHvJ1byifkwvg== X-Received: by 2002:a05:6512:3194:b0:4fb:242:6dfa with SMTP id i20-20020a056512319400b004fb02426dfamr1689323lfe.57.1691658562818; Thu, 10 Aug 2023 02:09:22 -0700 (PDT) Received: from [172.16.11.116] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id r11-20020aa7c14b000000b0051e26c7a154sm530135edp.18.2023.08.10.02.09.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Aug 2023 02:09:22 -0700 (PDT) Message-ID: <67ddbcec-b96f-582c-a38c-259234c3f301@rasmusvillemoes.dk> Date: Thu, 10 Aug 2023 11:09:20 +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-Server: rspam08 X-Rspamd-Queue-Id: C7CED40013 X-Stat-Signature: umi1roeieenxgbnkqtqfpkk3wwsydkyt X-Rspam-User: X-HE-Tag: 1691658564-751794 X-HE-Meta: U2FsdGVkX18MFndqOb58kIkxI38Gkdb/OvFpSv89QL6yrxxTyybJVkByNuyJBAKQrz1I3TEsLMPsHw4LGkt8/Bu8R0haTHOhn4q596o6tnwrUX7ksO1dyQ5H+wGNzGbm9YPFApiKCVCrzPeNQH/pLrrDYnoAbmmoKmRz1vr0pxuwz3gYdz/6Gx2OQPQZtdLqbjUjVdHpt1g4wa1Q7x0PPpIiVyJuzSY3+gz7Yea1gF5O0xQSJT+bQEAICEzGJNG7eY2OGdaC22x3no7eJybgymGt459qEB1cEFiibF0ZFoP64OmxNOf8BrRW/Ddt/OeFIxt/LG1G6QRcY3YLU/gn+mMht6DCr9Eee+RhYMEyOqcRYlhOirqqwcku8pR/26yqooP9f2z1xv8+86vUQy6r5+g/XujXIn3l0cDo4c4Q9xBcmRo5g6Hbwf12S4prU2TL28sytuoj2uhOVlBah2hVqgruWmPoNe0AUGDEejf8V6XeP5JmbDugbgJhlD0VL7RywV+4MEC7rcQsDjhW9O68D5ND8h0uEaA8An90kPZ+A/d4Jd0GVAtKWySDg+OSsNOD0Y1hA7k17U6avvwYBdArLKkNSMleiKrW2PCLD+FVKKxRbvzuOPk/wy7/CjMd06O9yfhXN0VWRzcgWk7UwKnm9wD++oQjfrMHA0ksgU3k43Vin6K6TrDDpolgKRrsQVkMz2zPgfj4g5Yo/smB6L5KchTxLSVUFoK8dxpnu94fP6rM9BTiIKQ7AzCRp4SUMlGsKiaH7DtrJAWy4fULuu/0q06pbYmovN13PrgwOeEpB+QPTfeipMWbYitGFsqUZEYfDBVKGo6DMcU5h5NaEC8/UK3caPazowYhTNMfbaTRqDTQUupzlEGiNILHEEv3F9iHUIyicANk1bozHOo467dQYKfr5mPsPfFkAm1OlHHe4htpaPO/rYdM+cG0YzraLyTKH5l/emqEp9ZydnQtwf9 Nv12Ui1d LunFkBcPsZQJOipe4hn2jq7aXgl4IZP/z01+25nTgopnCqkTnvK1+u6aXdl4lAuGRdW56zGOE6bgszihkzPaLYVv79LMfPClQOPyeE3jYSeXngdtmXexxt8YZEKHkyLj4JHoazbbEAuVSQTtcmOwPAGM5aD4+TlE8jclxQUdTpNnO8TCAUwpfCMKknP30tGng/VVKCS4w8V1W4o28FVoRjgCXp4RBH168rYNcBaalTeAEZoZXrbu/s1QF9AocEePzsBVCrSjobDYxZZ5tOdT2frTb0obMpKjKBzW5jZDBArJLEHZQ7Mb8Zfr6y7JkS1cf2wPRa4G5aNedPwa8reZmt+Vvxlh3M6GNf1H1bQN4KIuxbfQ= 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 10/08/2023 10.15, Petr Mladek wrote: > Everyone agrees that kernel.h should be removed. But there are always > more possibilities where to move the definitions. For this, the use > in C files must be considered. Otherwise, it is just a try&hope approach. > >> Also, please, go through all of them and tell, how many of them are using >> stuff from kernel.h besides sprintf.h and ARRAY_SIZE() (which I plan >> for a long time to split from kernel.h)? > > I am all for removing vsprintf declarations from linux.h. > > I provided the above numbers to support the idea of moving them > into printk.h. > > The numbers show that the vsprintf function famility is used > quite frequently. IMHO, creating an extra tiny include file > will create more harm then good. By the harm I mean: > > + churn when updating 1/6 of source files Well, we probably shouldn't do 5000 single-line patches to add that sprintf.h include, and another 10000 to add an array-macros.h include (just as an example). Some tooling and reasonable batching would probably be required. Churn it will be, but how many thousands of patches were done to make i2c drivers' probe methods lose a parameter (first converting them all to .probe_new, then another round to again assign to .probe when that prototype was changed). That's just the cost of any tree-wide change in a tree our size. > + prolonging the list of #include lines in .c file. It will > not help with maintainability which was one of the motivation > in this patchset. We really have to stop pretending it's ok to rely on header a.h automatically pulling in b.h, if a .c file actually uses something declared in b.h. [Of course, the reality is more complicated; e.g. we have many cases where one must include linux/foo.h, not asm/foo.h, but the actual declarations are in the appropriate arch-specific file. However, we should not rely on linux/bar.h pulling in linux/foo.h.] > + an extra work for people using vsprintf function family in > new .c files. People are used to get them for free, > together with printk(). This is flawed. Not every C source file does a printk, or uses anything else from printk.h. E.g. a lot of drivers only do the dev_err() family, some subsystems have their own wrappers, etc. So by moving the declarations to printk.h you just replace the kernel.h with something equally bad (essentially all existing headers are bad because they all include each other recursively). Also, by not moving the declarations to a separate header, you're ignoring the fact that your own numbers show that 5/6 of the kernel's TUs would become _smaller_ by not having to parse those declarations. And the 1/6 that do use sprintf() may become smaller by thousands of lines once they can avoid kernel.h and all that that includes recursively. But those gains can never be achieved if we don't start somewhere, and if every such baby step results in 20+ message threads. Rasmus